It appears that Twitter started rendering custom Emoji icons on twitter.com about a month ago. I took the opportunity to update my Emoji reference table with their icons and it looks like a full set.
They’re not particularly well drawn, and unfortunately will override native Emoji on operating systems that support them, such as Safari on Mac OS X.
I took this as a good opportunity to do what I’d been thinking about for a while – backing up and deleting the thousands of pointless remarks I’ve posted to the Web.
No sooner had I launched a demo version of Flamingo than I get an email from Twitter Platform Operations telling me to shut it down on the grounds that I was “resyndicating Twitter content” which is against their API terms of use.
The email was a rather anonymous message apparently sent from a customer service ticketing system of sorts. It was a casual threat of legal action, euphemised as follows:
“If changes have not been made to bring your service into compliance by [date] we will take steps to enforce our API Terms of Service. Thank you in advance for your cooperation.”
A lot of sites (particularly blogs) have Twitter feeds that are powered by JavaScript and based on the old API. A lot of these widgets will not be upgraded for various reasons and will soon stop working altogether. Many people don’t have the skills or resources to replace these widgets with the more advanced back end code that the new API requires. Flamingo helps front end developers by making it easy to configure and set up ajax services without knowing a server side language.
For the uninitiated, this means a simpler way to make authenticated Twitter API calls, and doing so on behalf of your app, not on behalf of a Twitter user.
I went straight ahead and added support in my Node library (mostly just so I could try the new stuff out) but I’m struggling to see much advantage in this feature.
After submitting my Latest Tweets plugin to the WordPress directory last week, I thought I’d do another one.
My “Latest Vines” plugin displays your Vine videos in a sidebar widget. Clicking the thumbnails plays the video in situ, and clicking the date takes you to the page on vine.co.
But nobody seems to be talking about it. (Except me. I can’t stop going on about it).
I suppose in the six months we’ve known about this, everybody who knew about the deadline has done something about it.
Putting these enlightened folk aside, it seems that a lot of site owners are blissfully unaware that (a) this is happening, and (b) that it affects them.
If your WordPress site displays your latest tweets, or uses any kind of unofficial Twitter widget, you should check it supports the new API. You should do this today. If your plugin is not up to date with the new API, it WILL stop working on or shortly after March 5th. I’m not trying to scare you – it is a thing.
Doing a quick search for ‘latest tweets‘ in the WordPress plugin directory the top five results do not support the new Twitter API. Sorting the list by the newest plugins, only one in the first four is compatible. Just this handful will account for thousands of broken sites come next week.
I wrote a few pre-thoughts on the new Twitter API last August, but I’ve only just now got around to migrating my numerous apps.
First to escape the cull so far is Twitblock. I was initially pleased to see that it wasn’t denied access to all its old functions – blocking, reporting spam etc.. But what I found is now a huge problem is the new rate limiting model. Continue reading…
I’ve run TwitBlock for three years and have always known that one day it will stop working and I’ll have to take it offline. However, it’s not clear to me yet whether I’ll have to take it down in six months, so I’m trying to avoid a rant for once (mostly).
I just don’t think the impact is clear enough at this stage. Most points in the announcement are either too grey, or just confirm a general direction we were already well aware of.
By way of composing my own thoughts, this is my reaction to some points in the announcement: