The future of WP to Twitter

May 5, 2010

Topics: Web Development, WordPress.

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:

  1. Let the plugin die
  2. Implement OAuth for the plugin
  3. Build a pass-through web service to act as an application interface with Twitter
  4. 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.

Implement OAuth

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.

25 Comments to “The future of WP to Twitter”

  1. I think OAuth would be the way to go!

  2. 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.

  3. @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.

  4. “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?

  5. 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 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.