Tonight I spent a couple hours troubleshooting a problem with my Tweetfave service and handling of links. Luckily I discovered it was a simple matter of keeping up with Twitter’s API changes. This service has been running so smoothly and the API has actually been pretty stable. I needed to dust off my PHP skills and dig in to track down and adapt to an important change.
Background
Tweetfave is a free service which monitors the tweets you mark as favorites (now referred to as “likes”), then sends them to you by email. Currently the system stats show over 250 users have tried the service, recording just under 400,000 tweets!
One of the handy features in Tweetfave is the “un-shortening” of the short URLs embedded in the tweet. Rather than showing a generic “http://t.co/xyz” link, the software will reveal the original URL.
Problem
This has all been working fine, but recently I noticed something strange where the URL decoding resulted in a link back to the original tweet. Instead we should be seeing the the links within the tweet.
Here’s an example with the original tweet which doesn’t have any links, but does include an embedded image which should have a Twitter image URL:
However when it’s processed by Tweetfave, the resulting email snippet shows a link back to https://twitter.com/i/web/status/831963043508596736 which is the original tweet:
Solution
It took a bit of trial and error, debug logging, and Google searching to find the culprit: the support for more than 140 characters in tweets. When Twitter added that support, they wanted to retain compatibility. Any API call which returned tweet text was still limited to 140 characters, with the link back to the tweet to read the rest.
It looks like the announcements came out in May 2016:
- Upcoming changes to Tweets — Twitter Developers
- Tweet: Information on the upcoming changes to Tweets is now on the developer site
- Coming soon: express even more in 140 characters | Twitter Blogs
They were a little fuzzy about when the actual changes would happen, but from my logs I think it was around October 2016.
In the end the change was quite simple:
- Include the parameters
extended_tweet=true
in the API requests - Retrieve the original tweet text from the
full_text
rather thantext
response field
With those changes in place everything works again. For example this tweet from TheNextWeb includes both an article link and an image:
Once decoded and sent by Tweetfave, the result included decoded links for both the article and the picture: