When I embed a tweet in my post, that’s all I want. But WordPress, and the Twitter API, wants to give me more. I don’t have to accept that.
What am I blabbering about now? Well in a recent post where I am talking about using WordPress to publish your own versions of the soon to be deep-sixed storify content, even the examples I used in my post exhibit a problem.
The tweets I am embedding by the WordPress oEmbed Magic are the ones in white. But what I get, and occasionally does not bother me, but what clutters the crap out of what I am trying to achieve, are prepended by an older tweet in the chain (background color a bit darker).
After a few rounds of swinging the code axe, I am cautiously optimistic I have an answer. Be warned. What follows involves code modifications to your theme’s functions.php
and for older posts, some clearing of stuff in your database.
Now that there are maybe three readers left (Hi Tom!), here we go.
As usual doing some WordPress Code Axing leads into a variety of answers but also often futile swings into StackExchange. But this suggestion offered for a different desire (removing media from embedded tweets) looked on target.
Way down in the Twitter API docs for oEmbed where the hide_media
in the exmaple is listed, just below is the one that sounds like I need hide_thread
When set to
true
,t
, or1
a collapsed version of the previous Tweet in a conversation thread will not be displayed when the requested Tweet is in reply to another Tweet
Bingo!
I add this bit of code to functions.php
1 2 3 4 5 6 7 8 9 10 11 12 |
/** * Hide threads for all twitter oEmbeds, using the hide_thread=1 query argument * ----- h/t https://wordpress.stackexchange.com/a/225081/14945 */ add_filter( 'oembed_fetch_url', function( $provider, $url, $args ) { // Target publish.twitter.com provider if( 'publish.twitter.com' === parse_url( $provider, PHP_URL_HOST ) ) $provider = add_query_arg( 'hide_thread', 1, $provider ); return $provider; }, 99, 3 ); |
And nothing happens. I make sure my caching plugin is off. No dice.
I step back, try a different swing. I poke around the content in the Chrome Inspector, and find a class for the divs that contain the tweet I want to hide, it is .EmbeddedTweet-ancestor
. I experiment with adding a display:none;
and it seems to work on one tweet.
So I update my CSS, reload, and… nada.
I do more digging, poking, experimenting in CSS. After way too much time, I learn that the way the content is structured inside this mysterious entity known as the #shadow-root
my CSS cannot override it.
Put the axe down now. I’ve reached my limit, so I shrug and cast off a question myself to the WordPress StackExchange.
I usually have good luck and get nearly instant and multiple replies. This time, I got one, but it seemed vague.
I think your code is good, but the oembed is actually in transient so your code isn’t in use until the transients disappears, you may have to clear them.
I sort of know of WordPress Transients, they flood the post_meta
table in the database. They are basically options that expire. Whatever.
I installed a plugin that lets me see storied transients but I could not find any. Another missed axe swing. It’s back to the Google Flail with a search on wordpress clear transients oembed cache
and it’s a good one. I found a post that explains how to delete some database post_meta data that the oEmbed plugin caches.
Now I am in deep, inside phpMyAdmin the cpanel access to my wordpress database. I’m in the wp_postmeta
table. As a test I am going to look for the cache files for one post with embedded tweets (one of the ones I populated with stuff from storify), a post ID of 65496
. The embedded tweets all gave an earlier ancestor:
This is the query to find all postmeta that have _oembed
in the name
1 |
SELECT * FROM `wp_postmeta` WHERE `post_id` = 65496 AND `meta_key` LIKE '%_oembed%' |
Lots of them:
I select all of these (breathing deeply in case I am about to cause major damage) and delete them. When I reload the page… BOOM! I killed those ancestor tweets.
If I was going to really start whomping with the axe I could nuke them across my site with a mySQL query
1 |
DELETE * FROM `wp_postmeta` WHERE `meta_key` LIKE '%_oembed%' |
But I might just wait a bit before going wild. Most of these should disappear, right? There is an expiry value for a timestamp.
At this point I may just lean on the axe in pride.
I guess I could wrap my function in a small plugin for someone who does not want to muck with their theme files (and when I say muck with I mean doing this via a child theme, you should never ever ever edit a theme that can be automatically updated. You will lose all your stuff)
There is nothing as satisfying as a good axe chop
Featured Image: 2010/365/83 Axe Marks The Spot flickr photo by cogdogblog shared into the public domain using Creative Commons Public Domain Dedication (CC0)
This is another great deep dive Alan. I have not quite got to the stage of carving things out in the backend, but have started down the road of a [Child theme](https://collect.readwriterespond.com/a-further-reply-to-chris-aldrich-in-regards-to-the-indieweb/) thanks to your help. I am interested in adding your solution at that level. It really bugs me how the [default oEmbed](https://collect.readwriterespond.com/storifried/) bakes in the parent post.
P.S. Am I the third reader or a lucky forth?
[Via collect.readwriterespond.com](https://collect.readwriterespond.com/?p=645)