Exploring some WordPress functions and hooks, I discovered something new to me about how oEmbed functions in WordPress. I’m not sure how much the current set-up differs from prior ones, but now that I see how the current one works, one of my main concerns all along – the eventual purging of tweets ((Sometimes referred to in Twitter documentation and code as “statuses,” but that term never caught on. I wonder if it’s even used by Twitter programmers anymore.)) by quoted users or by Twitter itself – has been somewhat allayed, and directions for developing Better WP Twitter Embeds are much more clear to me now.
I’d like a post written today to make sense tomorrow, whether or not someone whose tweet I noticed today is still there tomorrow, and I’d even like a post written two years ago still to make sense two years from now, and twenty years from now, and two hundred years from now, or at least to be re-constructible. Furthermore, if a tweet has been deleted, that fact should be signaled somewhere, even if our eventual modifications ensure that it remains displayable just or mostly like a never-deleted tweet. Finally, other options for display – such as whether to include “conversation” or “cards” (as previously discussed) – should be easy to set without anyone having to hack anything, and without having to apply Twitter’s native embed routine on every tweet.
Today, right now, typing `https://twitter.com/CK_MacLeod/status/747821033344798721` in my edit panel will produce a “rendered” tweet that looks like this:
The Norm
However, if I deleted the Tweet – the rendering would not occur. Instead, one of two things – under current conditions – would happen: If I typed the URL to the deleted tweet in a new file, no embedding of any kind would occur, and the URL would just sit there. However, if I return to the file where the tweet was already embedded, I’ll get something different: The text of the Tweet, but rendered as a simple blockquote rather than as a fully rendered tweet.
I believe that this functionality – preserving the deleted tweet content – is somewhat new, and that in the past the content would simply have been lost, though it would be difficult to test the proposition, for a number of reasons.
For illustration, here’s the output from a file in which I had embedded two tweets (by pasting their URLs and letting the magic happen) when both were still “live” – as refreshed after I deleted the first tweet from Twitter:
Rendering Deleted Tweet – Case 1
And here’s what happens after I paste the very same URLs in a second, new post:
Rendering Deleted Tweet – Case 2
Why does it happen this way? In short, under normal circumstances, when you type a tweet’s URL in a WordPress post, the magic of oEmbed and the magic of WordPress and the magic of Twitter combine to produce a triple-magically rendered tweet. Behind the scenes, WordPress stores the tweet’s raw HTML in a so-called “post meta” variable. It also happens to store the time of the tweet in UNIX form (number of seconds since January 1, 1970). So the relevant post meta variables look like this:
Case 1:
[_oembed_28223f0bac23b5080c1c160e0fed7ff3] => Array
(
[0] => <blockquote class="twitter-tweet" data-width="550"><p lang="en" dir="ltr">Scuse me while I test something out here.</p>— CK MacLeod (@CK_MacLeod) <a href="https://twitter.com/CK_MacLeod/status/747820088141615104">June 28, 2016</a></blockquote><script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>
)
[_oembed_time_28223f0bac23b5080c1c160e0fed7ff3] => Array
(
[0] => 1467129206
)
[_oembed_59172fcca5f6ae6d0aa14bd7922b37ca] => Array
(
[0] => <blockquote class="twitter-tweet" data-width="550"><p lang="en" dir="ltr">Scuse me while I test out a second thing right here.</p>— CK MacLeod (@CK_MacLeod) <a href="https://twitter.com/CK_MacLeod/status/747821033344798721">June 28, 2016</a></blockquote><script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>
)
[_oembed_time_59172fcca5f6ae6d0aa14bd7922b37ca] => Array
(
[0] => 1467129441
)
Case 2:
[_oembed_28223f0bac23b5080c1c160e0fed7ff3] => Array
(
[0] => {{unknown}}
)
[_oembed_59172fcca5f6ae6d0aa14bd7922b37ca] => Array
(
[0] => <blockquote class="twitter-tweet" data-width="550"><p lang="en" dir="ltr">Scuse me while I test out a second thing right here.</p>— CK MacLeod (@CK_MacLeod) <a href="https://twitter.com/CK_MacLeod/status/747821033344798721">June 28, 2016</a></blockquote><script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>
)
[_oembed_time_59172fcca5f6ae6d0aa14bd7922b37ca] => Array
(
[0] => 1467130023
)
The reason that the first tweet, in Case 1, is not rendered as a tweet but instead as a simple blockquote is that Twitter returns an error. The error and error-responsive code do not turn up in the page source, but can be found via inspection with Developer Tools, found in an in-between state (prior to javascript re-rendering, I’m presuming) as the class “twitter-tweet-error” and some additional code added to a blockquote. It looks like this: `<blockquote class=”twitter-tweet twitter-tweet-error” data-width=”550″ data-twitter-extracted-i146713229858629935=”true”><p lang=”en” dir=”ltr”>Scuse me while I test something out here.</p>
<p>— CK MacLeod (@CK_MacLeod) <a href=”https://twitter.com/CK_MacLeod/status/747820088141615104″>June 28, 2016</a></p></blockquote>`. The rendered Tweet also shows up, eventually, as a blockquote, but only after extensive additional code has been imported, placing the tweet text deep within a sub-sub-sub-div.
What this means for me for now comes down to two facts pointing to further research: 1) The content of deleted tweets, if ever previously fetched and rendered, should remain “there” in an affected post’s post meta, and 2) it should be quite possible to emulate the rendering process programmatically, whether for the sake of presenting deleted tweets in a way that marks them as such and also harmonizes aesthetically with “normal” tweets, or whether for the sake of automating and customizing the display in other ways, without having to resort to hacks.
