In June of 2010, Twitter will be permanently disabling basic authentication in favor of the OAuth protocol for authentication. For WordPress plugins which make use of the Twitter API (Application Programming Interface), this is a change which will have significant repercussions.
The specific repercussion will be that every implementation of a plugin will need to be registered with Twitter as a separate application.
This means that the development of WP to Twitter will need to move in a slightly different direction. After pondering a bit, I’m left with four plausible choices:
- Let the plugin die
- Implement OAuth for the plugin
- Build a pass-through web service to act as an application interface with Twitter
- Associate with a 3rd party web service in the same capacity
These all have downsides, obviously — but I want to lay out my thoughts on each possibility and I’m asking for comments from the users of my plugin on their preference.
Death of WP to Twitter
Although it’s not really my favorite option, I have to acknowledge that it’s plausible. It’s certainly the easy answer — maintaining an even moderately popular WordPress plugin is a lot of free labor. I already spend more time on maintaining than I really should, from a financial perspective, and this may push it over the edge.
This would be a fair amount of work for me, although not insurmountable. The real downside to it would be how much work it would be for users — every one of you would have to register one application with Twitter for every site where you installed the plugin. With one site, this may not be a big deal — but I know it could be a real pain for people with more than that.
It’s not without some potential advantages, of course – when you’re registering your own application, you could customize the application name, the home URL (Uniform Resource Locator) for the application, etc.
Build a pass-through service
One way around the Oauth mess is for me to build a separate service which would handle actually connecting to Twitter. WP to Twitter would authenticate with that service, and pass the post off to Twitter. Again, this would be a lot of work — but, more significantly, it would involve some definite expenses.
I’ve been happy to maintain this plugin for not-much-better than free, but when it comes to incurring expenses, I start to feel a bit unexcited. It’s not like WP to Twitter is a commercially viable business, and I have expectations of profit from it — but I’d prefer not to find myself going into the hole because of it. I’d probably need to see an increase in donations to make this feasible.
Use a 3rd Party Service
Obviously, if I can build a service to connect with Twitter, so can somebody else. This is almost certainly the easiest solution which keeps the plugin usable — but it does mean creating a dependency on a 3rd party to keep the plugin functioning. Depending on Twitter is just natural; obviously, if Twitter goes away, the point of the plugin is lost. Depending on somebody else is something I’m less certain of, on the whole. There’s a reason, after all, that the plugin allows for use of URLs without an external shortener.
Give me your thoughts
This is very important to me — I want to know what direction you’d like to see WP to Twitter go. Please let me know! Do you know another solution? Do tell!
And if there are no responses…well, that has a pretty obvious meaning as well.
Mildura; July 8, 2010 at 7:27 am
I think OAuth would be the way to go!
Michael Eh?; June 29, 2010 at 6:25 pm
I find WP to Twitter one of the finest utils out there. I think that Twitter is making the change that THEY should have to give support to developers to switch over. Besides, it’s August 25th is the switch over according to Twitter API (Application Programming Interface) section.
Joe Dolson; June 21, 2010 at 6:26 pm
@Daniel15 Not under the Twitter setup, without providing my own secret key in plain text — which I’m not going to do. However, there have been changes in their policies which specifically apply to open source applications which will make a significant difference. Essentially, plugins will be able to be registered as child applications of the plugin; the plugin will be registered, and instance will be registered as a child of the original. Doesn’t sound simpler, but it will be much easier to work with for users.
Daniel15; June 21, 2010 at 6:11 pm
“every one of you would have to register one application with Twitter for every site where you installed the plugin”
Couldn’t you use the one application across multiple sites?
Gaz; June 15, 2010 at 8:09 pm
I hear ya Joe – I thought I was onto something with scheduled posts – setting the publishing date into the future (even just a couple of minutes) generated the short URL (Uniform Resource Locator) into the custom fields and it seemed to be going well for a few posts, then it went back into its old habits.
I stumbled across something on wp.org a hour or two ago – one of the newsletter plugins (sorry forgot which one already – will check if its valuable) had a post on their own site about scheduling issues in WP 2.9 and 2.9.2 that didn’t appear in 2.8 or 2.9.1 related to the interval in wp-cron.php between checks for scheduled posts – default is 1 second, and the patch was to rejig it to 20 seconds (ah! Post Notifications plugin – check their forums under files and patches section).
Apparently this fixed scheduled posts not being published. The connection with previous musings about time-outs fetching the short URL or sending to twitter was what made me think of it.
In the same vein, I’m also wondering if reader activity on-site, coinciding with a click to publish, could be causing a “script stutter” although it’s generally a bit too consist for that, for the people suffering from it.
Joe Dolson; June 15, 2010 at 4:10 pm
@Gaz I’ve looked at it, and it’s a bit puzzling. I’ve been primarily focusing on one of my other plugins while waiting on Twitter, but I’ll be putting some attention in on that issue soon. I just haven’t found anything concrete to work with yet…and I hate random bug exploration…
David; June 15, 2010 at 4:00 pm
Gaz; June 15, 2010 at 3:59 pm
Fantastic news Joe
While you’re twiddling your thumbs waiting for twitter to finalise things … any work on what’s causing the shortening errors? Any hint of it getting straightened out? Thanks for the ability to switch the error messages off by the way – great move.
Joe Dolson; June 15, 2010 at 3:33 pm
The authentication change is supposed to happen on June 30th — two weeks from now. I’m still waiting on making a decision about what I’m going to do. The Twitter API (Application Programming Interface) development team has made some changes to the API implementation which significantly simplify the OAuth process for open source applications, which is fabulous news — however, there are still some changes to be worked out. I’m waiting to see what the final outcome will be, rather than find myself needing to make changes twice.
However, what you need to know as plugin users is quite simple: I will be implementing OAuth support in the plugin. There will still be some hoops for you to jump through in activating the plugin and registering it with Twitter, but nothing like what it would have been with the previous work flow.
David; June 2, 2010 at 10:47 am
Do we know when in June this is supposed to happen?
I just tried a test post from nomorepencils and it worked. I have abandoned the link shortener (both bit.ly and cli.gs) because something was happening somewhere that was unpredictable, but the full link post worked today.
Michael; June 2, 2010 at 10:28 am
I don’t really have much input on how to fix but I do like the ease that WP plugins give a blogger like me who does not code. The takeaway for me from this post is to keep an eye on the best way to get my posts to twitter automatically.
thanks for sharing.
Ali; May 30, 2010 at 5:15 am
it is sad that wordpress won’t be able to use this plugin but I have recently started using Twitterfeed for all my wordpress blog feeds to be posted to twitter. It is a third party application offcourse but better than nothing at the moment.
Thanks for the article.
David; May 21, 2010 at 7:05 am
Now here’s the thing. I posted several posts from nomorepencils today. One got through with a bit.ly shortner. The second did not post at all, and when I disabled the shortener it posted with a number string but no URL (Uniform Resource Locator).
We are not in June yet, so Twitter has not disabled the authentication, so something else is happening. Any ideas?
I think Wp to Twitter is a GREAT PLUG-IN. It’s up there with Mark Jaquith’s ‘Page Links To’ and if there is a way to keep it floating, I would love it to do so.
Gaz; May 7, 2010 at 1:13 am
Joe, I did a lot of thinking overnight about how you could “profit” or “benefit” from the plugin under the new twitter regime.
One option that I came up with comes out of the affiliate marketing plugins sphere – monetising wp-to-twitter directly is going to be very difficult, therefore why not leverage it to do what it does ….
(This is rough thinking and not yet polished)
If you set up the plugin to be a proxy marketer for your own sites, you could massively leverage the user base without becoming a spammer or pain in the neck, the following is a rough idea which I believe could be workable. It is based upon the concept of “small percentage shared benefit to the author”. I’ll lay it out in steps …
First you inventory your own websites and create a system that RSS (Really Simple Syndication) feeds into a flat text file a bunch of “pseudo tweets” containing topic titles, shortened links, and optional comments per pseudo-tweet. This flat file is in a publicly accessible “feed source” folder on one of your hosts.
Next, you add a “tweet share” engine into the plugin – in essence, once every X days (set by the plugin user, with an example range of between 7 and 30 days) the tweet-share engine grabs a random pseudo-tweet from the feed-source file and tweets it out to the plugin user’s account, promoting your particular post or URL (Uniform Resource Locator) within that tweet.
Depending how far you want to develop the idea, you could have your tweet-source file auto-filling and rotating from something like RSS feeds off your site, or a static list you manually input to promote a specific set of topics or pages etc. You could even have it as a mix of that with a “fixed” list and a “dynamic” list within the file.
You could then begin financial leveraging of your own sites via affiliate marketing or direct ecommerce, chargeable services and plugins, or whatever. The concept being that it would give you a far greater benefit and incentive to continue with the plugin under the new twitter system. That’s not to say you should support it as deeply or extensively as you have done. There needs to be a demarcation line between the extent you’ll support it free, and the point where you start charging for one-on-one support.
An extensible for this idea is that from your existing known user base, you could identify competent individuals and offer them a “support service license” whereby they become associate support techs who receive “assignments” from you in response to paid support requests via an interface you set up. Some thought would need to be given as to revenue split and method, but it’s a workable solution I’ve seen on a number of sites for a variety of scripts and plugins. Again, this would derive income for you for continuing development, while removing the support burden, and by automating allocation via an interface, it removes admin overhead too.
As I said, it’s a rough idea, but it should e workable, and it would offer a reason to continue with the plugin, beyond doing it purely for the joy of it.
Hope it helps you somehow
Gaz; May 7, 2010 at 12:57 am
The bit I forgot to mention –
But the users themselves are already registered with twitter – to most of them this will just appear as additional info to input to twitter. Very likely the only people who will see it differently are the developers and advanced webmasters like you and I.
I really now believe this is the wrong “issue” to be focussing on – see next comment from me.
Gaz; May 7, 2010 at 12:52 am
If you’re not heavily involved with ecommerce, I can understand your reluctance on it, however the many WP users who also have shopping cart sites are very much accustomed to having this method within payment service modules on their sites. It’s not such a trauma as you might be thinking.
The other factor re: registration generally, is that although everyone bitches and baulks about having their details registered on gazillions of websites, it’s a basic fact of online life that it happens, and there’s not much that those of us in the great unwashed masses can do about it – heck, most of us even contribute to the mess by requiring users to register on our blogs and ecommerce sites. Even just posting a comment on your blog, here, requires us to input a name, email, and optionally our website – the point is that it is the norm to register everywhere online, users are used to it, and I don’t see any of that changing.
I very much doubt that OpenID, OAuth, or any of the other competing methods are ever going to do away with the need to register somehow, everywhere. Remember Microsoft’s Wallet system? It was supposed to be a global and ubiquitous system that did away with the need to ever register anywhere online ever again – didn’t last long did it? If even Microsoft cannot force a universal system onto everyone, I seriously doubt twitter can, and that will relegate it to “yet another” place where users have to register some details.
I suspect focussing on the registration side of it is a red herring in moving forward on this. twitter will find out soon enough that the admin overload (for them) of treating every install as a separate app will become far too burdensome, and they’ll then have to take lessons from the payment gateways – why reinvent the wheel?
Joe Dolson; May 6, 2010 at 3:41 pm
Even if they do handle the requests this way, it doesn’t change the fact that nobody can register the application without providing a callback URI (Uniform Resource Identifier). As a result, any use of the application will require registration with Twitter – and we’re back to square one. That’s what I don’t really want to do.
@Bud There’s no cost for me to creating this as, essentially, an application framework using OAuth. I would, however, pretty much need to stop providing any support at all to users as relates to interactions with the Twitter API (Application Programming Interface), since one of the consequences of this change would be that every user would be individually answerable to Twitter for their use of the API; if they use it in an automated way that Twitter doesn’t approve of, they might be shut down — and I can’t be answerable to that. The last thing I want to deal with is a bunch of people complaining to me because Twitter shut down their implementation of the plugin.
Bud Green; May 6, 2010 at 2:56 pm
At the risk of sounding ignorant — oh, what the hell — I’d vote for at least kicking the tires on OAuth before ruling it out as an option. It sounds like a royal pain in the ass, of course, but that translates as “challenge” to many web developers. And there are many, many people like me who rely on way-cool plugins like this one to develop their own projects.
Is it cost-effective? Will it pay big dividends? Do end users like myself even understand the API (Application Programming Interface) questions you’re asking? “No” is the most accurate answer to all of those questions and more.
On the other hand, this is your baby … you shouldn’t show it the door just because it can’t pay for its own diapers. In this economy, I’m learning, you build audience first and then look for ways to leverage that audience into sales, contacts and/or other opportunities. With WP-to-Twitter, you’ve got the rapt attention of a growing, plugged-in audience, and that’s bound to pay dividends somewhere down the road.
Newspapers offer a useful analogy: Web advertising revenues remain a pittance compared with print revenues, so the ROI for online fails to impress. As part of a long-term strategy, however, the investment makes sense as a necessary prerequisite to developing and selling online content. This is difficult to justify during a time of scarce resources and shrinking newsrooms, and yet the culture shift continues to accelerate. When somebody invents a valid business model for online news access, all that sacrifice will pay off — but only for those companies that made the investment.
I don’t know nuthin’ about no APIs, just as you probably don’t know much about running a newspaper or news site. But if you make my job easier and my site succeeds as a result, I’m going to recognize that added value and contribute as finances permit. That’s the power of open source; we’re inventing the new business model as we go.
Gaz; May 6, 2010 at 2:42 pm
Just a quickie – wondering …. in payment service APIs they have a send-field that is used for the call-back URL (Uniform Resource Locator). So when your transaction and payment amount goes from your website to the service for the customer to pay, one of the data items is the location of the call back URL for the API (Application Programming Interface) on your site. (It’s pretty basic php structuring to capture that full URL).
Has twitter yet published anything to say that the call back URL can be passed to them WITH the tweet to be broadcast?
To me it’s the only logical solution for them – sure it’s a multi-step verification –
– pass message package and OAuth and callback URL to twitter
– twitter calls callback URL to verify user’s non-public part of OAuth
– callback file passes back the yoyo-ing string and URL etc
– twitter mutters “darn” and then publishes the tweet
It gets long-winded (just look at any API payment module in osCommerce) but it’s the only way I can see it working without EVERY install becoming a separate registered application – think ahead to WP 3.x and all those multi-blog sites it’s going to spawn.
If twitter don’t allow for something like the routine above, it’ll kill twitter dead in it’s growth tracks … but maybe that’s what they’re trying to do?
… and this was supposed to be a quickie ???
Joe Dolson; May 6, 2010 at 2:27 pm
Well, it’s the first thing that occurred to me.
What I’ve concluded would need to be done is that every user would essentially be re-registering the plugin as a unique application — it seems like there’s no reason that they wouldn’t be able to input a callback URI (Uniform Resource Identifier), but it’s an utterly stupid way to deal with this type of application.
At this point, I haven’t chosen to take the time to really work through the options — I’m trying to ascertain the value of actually doing anything at all, first.
Gaz; May 6, 2010 at 2:24 pm
Cross posting there Joe – I missed your first reply.
If the call back URL (Uniform Resource Locator) is the only or main hurdle, then it sounds to me like what they’re implementing is a variation of the PayPal API (Application Programming Interface) (which uses call backs to verify payment made/received) with possibly the Amazon style “secret keys” authentication. If so, they’re serving a stir-fried solution, mixing multiple existing methodologies into one mashup. Yuch.
Have you identified if the call-back URL entry can be input by the registering user yet? When I clicked through to the link at twitter (at the top of your post) it looks like twitter thinks everyone is going to be a programmer developing their own apps, without allowance for tools like yours, whereby they should be providing a common user registration for existing tools with tens or hundreds of thousands of existing users.
….. gaz puts tin foil hat on …..
What’s the betting they make this as difficult as possible to kill off independent mass-user developers like Joe, so they can introduce a paid service equivalent? You read it here first folks.
Gaz; May 6, 2010 at 2:13 pm
Tricky one this Joe.
Personally I’m dead against all this multiple layer obfuscation that goes on with API (Application Programming Interface) keys and the like. To understand that, you need only look at one of the oldest APIs around – the PayPal API – it uses simple, user recognisable keys – your paypal email address and website URL (Uniform Resource Locator). If you get hacked, you can recognise instantly if someone has messed with them.
On the other hand, you have the Amazon Associates (affiliate) API – it uses a simple associate ID comprising nametag+country_code – yours might be joe100-20 for the USA program. But then it introduced the API secret key and API ID key. The secret key looks like an MD5 hash string, and the ID key is a completely non-rememberable numeric string – no way to recognise if those have been interfered with or replaced by a hacker.
To me, it looks like OAuth and twitter are going down the Amazon style route – if that’s true, I’d opt for option one – drop the plugin and let someone else have the headaches. OpenID (a similar scheme) has been causing massive headaches for the developers at SMF Forums – the forum software equivalent of WordPress in the open source community.
As far as setting up a passthrough service, either personally or giving it to a third party, nope – that’d kill the plugin for me. I build multi-language WP sites for clients, and as soon as they say they want this or that translator plugin and it’s one that passes the translation through an API to the plugin authors services, I ditch the client and project. I don’t like potential situations where a site could be held to ransom by an external service.
Keeping it going via some form of subscription or fee … I think you know in your heart of hearts what would happen there? It’d kill it for you. Open source webmasters don’t generally like to pay for something that was free, or is available from an alternative author for free.
What you may have to do is take the nappies/diapers off WP-to-twitter, and let it grow a bit – combine it into a service for posting to facebook-myspace-linkedin-squidoo and so on, as an all-in-one plugin similar to what happened with the various inbound-autoposting plugins that became WP-Robot. Add in a WP to web-based SMS broadcast function and the pro-marketers will likely be all over it like a bad rash and willing to pay worthwhile money for it. Unfortunately, you’re then into the price realm where your average WP.org user won’t touch it, and it’d get dropped from the WP.org plugin repository.
You’ve got a tough choice ahead, and it’s always hard to kill your own baby if that’s the route you choose, so I don’t envy you the decision making.
Joe Dolson; May 6, 2010 at 2:05 pm
The main reason is the requirement from Twitter’s application registration that I provide a callback URL (Uniform Resource Locator) for the app — which means that I need to have a known URL to provide. With each installation on a separate URL, that’s not possible for me to provide.
Alec; May 6, 2010 at 1:48 pm
How about implementing OAuth with the twitter api key of a single WP to Twitter app hard coded. More enthusiastic users can create their own app, replace keys etc, whilst others can use your default app, plus it’d promote the (awesome) plugin.
Rob Mason; May 6, 2010 at 5:56 am
I’m a big fan of WP to Twitter as it just works, so my personal preference would be to keep it going via the OAuth option.