If you’re the sort of person that takes umbrage easily, don’t read this post, skip to the next one.

Debugging WordPress plug-ins connecting to third-party services can be easy, if you think about what you’re doing.

One of the great strengths of WordPress is that it’s an enabler.  That is, it enables people to do something they may have never done before – build and run a website.  But just as you don’t need to have done it previously to parent a child, or own a pet, when you create a website, there comes with that certain responsibilities …

Being the proud parent of a website, any website, demands that you familiarise yourself with all the essentials of web-administration.  This is a set of skills and tasks that requires a “Jack-of-all-trades” approach to self-tuition – you have to get to know something about everything.  It’s not like having a garden that you can just potter around in, and if it all goes to pot, then what the heck.  Websites have direct impacts on other websites, particularly if yours gets used as a re-routing hub for malware – but that’s a topic for another day.

One of my most regularly used WordPress plug-ins is the excellent WP-to-Twitter plug-in by Joe Dolson.  There are other twitter plugins out there, and each of them have their own peculiarities and features, but I’ve found WP-to-Twitter to be the one that suits me.

Before Twitter changed their authentication system for external applications to login and post tweets, or retrieve them for display external to the twitter system, all twitter plug-ins required just your twitter username and password.  After they switched over to an oAuth system, life became far more complex.  For Joe and WP-to-Twitter users, this meant that each website using the plug-in had to be registered as a twitter application, and the webmaster had to get their own personal set of authentication codes for each of their websites.  On WordPress MultiSite or MultiUser installations, this meant that each sub-site (or blog) had to become its own twitter application.  This is no different to how Google AdSense and the eBay Partner Network require each site and sub-domain to be authenticated individually.

WP-to-Twitter was one of the first plug-ins to embrace this new authentication requirement, and Joe even considered giving up the plug-in entirely at one point because of the implications for users.  Community support and pressure persuaded him to do otherwise, and so the plug-in continued.  The complexity introduced due to the twitter oAuth system brought with it problems.

Prior to oAuth, WP-to-Twitter was a much simpler code set and a very well behaved one.  From the outset of including the oAuth requirements there was an avalanche of bug reports.  Many were not genuine bugs but simply perfect demonstrations of PEBCAK (Problem Exists Between Chair And Keyboard) – an acronym that will be familiar to network administrators worldwide.  In other words, it was user error, not programmer error.

Joe got so overwhelmed with support requests repeatedly asking the same thing, that he published a WP-to-Twitter FAQ on his blog, hoping it would stem the flow.  It did not.  If anything, it accelerated it.  Google and other search engines now had an indexed page containing the exact same error messages that people were inputting to look for help, and the comments section of that FAQ page has exploded to include well over 1,000 plug-in users’ queries.  90% of those queries could have been answered by reading the FAQ’s at the top of the post, but no, everyone insists they’re unique and different, and that the common scenario FAQ answers don’t apply to them.  PEBCAK at work again …