Quite a while ago (like, in at least 2009), I started thinking about regaining control of all the content I was producing online. I was posting photos to Flickr, saving bookmarks to Delicious. I started Tweeting. I was checking in. All fun and games, and all of those services offer great tools for interacting with them (let’s face it, tools that are much better than WordPress’, because they are focussed on one thing). So I figured, why not write importers for these services and pull my content back over to my WordPress. And keep doing it periodically, so that I could keep using those tools. I want WordPress to be my “home on the web”, my digital hub, but I want to use these neat tools with their fancy apps and what-have-you.

Very quickly, I realized that if I was going to do anything useful on most web services, I’d need to be able to authenticate with them. No biggie, right? I know my username and password… Oh. Right. OAuth. Turns out that most web services use OAuth (or something similar) to authenticate, and it turns out that that’s actually a bit of a bear to implement, when all you want to do is write a simple little Twitter importer. And then again for a Foursquare importer. And a Flickr importer.

What I needed was a shared, generic authentication framework that would do all the heavy lifting for me. I would tell it I wanted a connection to specific service, and if it didn’t have one, it’d walk the user through the process of getting one. It’d give me a standardized format of authentication credentials and abstract out all the complexity of making authenticated requests against those services. Then it would make me a coffee*. What I needed, was Keyring.

And so Keyring was born. Basically it’s a bunch of code that’ll handle external authentication with a web service so you don’t have to. It’ll store tokens/passwords/whatever, can talk to all kinds of different services, and is really, really extendable. It also has hooks. Lots of them. So if you want to do something custom, you probably can. It’s intended to be a foundation for writing other plugins, and really doesn’t do much interesting on its own.

I already have importers written for Twitter, Delicious and Foursquare which are based on Keyring and so far they’re working pretty nicely. There’s a lot of work to go on this project though. For Keyring to be a truly powerful framework, I need to:

• Drastically improve the UI, which is a hodge-podge of hideousness at the moment
• Improve a few parts of the Core UX which are pretty clunky right now
• Put in some more failsafes/helpers for making sure things are up and running before allowing plugins to use Keyring
• Improve internal security
• Tighten up Permissions/Roles restrictions all over the place
• Handle multi-user blogs (especially around token storage)
• Work on Multi-Site
• Support more services (preferences? suggestions?)
• Figure out a good way of allowing people to drop in their own Service extensions (and not overwrite them with updates)
• Improve the handling of auth flows in other plugins, and preferably move as much of that logic as possible into Keyring Core

I’m slowly working on this, but it’s all kind of a personal project at this point, so it’s just a few hours here and there. My main goal is to get it functioning so that I can get my content back. Once that’s done, then I’ll spend more time tightening it up for other/platform use. I also have a couple of other “companion plugins” that I’m working on — auto-linking text for Twitter @mentions and #hashtags, mining posts and downloading remote media (e.g. Instagram images) and some stuff around geo for mapping things like Tweets and Foursquare checkins (all the geo-data is imported in the importers I wrote).

Next on the list is abstracting and then releasing the importers that I have. That will give people something more tangible to use as an example. After that I’ll be working on a Flickr importer, but that’s a pretty big project in and of itself.

So, what do you think? Useful? Waste of time? Massive, gaping, horrendous holes? LMK (in the comments) and we’ll see what we can do.

And you know the drill — patches welcome

* Sadly, Keyring will not make you coffee. Yet.

Table Prefixes

Did you know that WordPress supports to use of a different table prefix for each installation? You may not really have noticed but it’s even an option in the wizard-style installer if you don’t manually configure your wp-config.php file during setup. This means that you can modify the names of the tables used for a specific installation of WordPress to avoid clashing with other tables that may already exist within your database. It also means that you can easily run multiple copies of WordPress from a single database by using a different table prefix on each install. I just use a different prefix for each major version of WordPress (wp28_, wp29_, wp30_) and then I can install them all in a single database and have easy access to everything.

For the sake of my own sanity, I opted to install WPMU in different databases (named according to the version I was installing) since it creates lots of tables.

Multiple Installs

Apart from the table prefixes trick, I like to use the version of the install as the name of the blog (“WordPress 2.9″) so that I always know what I’m looking at. I’ll set all of the admin accounts to the same details, and then import the same set of test content (via a WordPress Export/Import). That gives me a consistent environment to work from.

Symlinks

So now you have a bunch of different installations of WordPress, all using the same database (although different tables). You need to get your code in place so that you can test it on each version. One option would be to put a copy of your plugin in each wp-content/plugins directory, but then that quickly gets out of control if you make changes to any of them while you’re debugging/developing. A better option is to put your code in one place, then symlink it into location in all of your installs. I use something like this:

ln -ns ../../../dev/pluginname pluginname

(executed from within the wp-content/plugins directory of each install, and assuming a directory called dev/pluginname containing the plugin, at the same top level as all of your installations). This links wp-content/plugins/pluginname from each install back to the same set of code, and allows you to modify it in any of them and have that change be reflected in them all.

Capability Checks

Rather than checking for a specific version of WordPress (which is actually easy to do), I usually prefer to test for specific functionality. For example, to see if you can use the WP_Http() API (introduced back in WP 2.7), you could do something like this:

if ( function_exists( 'wp_remote_get' ) ) {
    // Can use WP_Http()
}

If you really want to check for a version of WordPress, then you probably want something like this (note that the $wpmu_version check in this case is to make sure we’re NOT using WPMU). You might need to declare it as global if you’re doing this within a function:

if ( version_compare( get_bloginfo( 'version' ), '2.7', '<' ) && empty( $wpmu_version ) ) {
    // do stuff
}

Tracking Major Changes

The other big issue is keeping track of what changes from version to version and how that might affect your plugins. Probably the easiest way to at least get a cursory glance at this is using the announcement pages on the Codex. For example, here is the announcement page for Version 3.0. If you need more detail, you can also try getting a report from Trac, like this one which covers everything in 3.0. Combining these, you can come up with a bit of a list of things that are likely to affect your plugin, depending on exactly what it does. As usual, the more you stick to the documented APIs, the less likely that your plugin will break over time. I personally use this to find new/better ways of doing things and harnessing new features that are introduced more than anything else.

svn switch http://svn.automattic.com/wordpress/tags/2.8/

Once that was complete, I logged into my admin panel and completed the DB upgrade, then I had to check some plugins. I had these problems/changes:

• TinyMCE Advanced had an update available, so I did that,
• One Click Plugin Updater seems to clash with the new Plugins page, and I don’t really need it now anyway since its functionality is in core, so I deactivated it and then deleted it
• IntenseDebate seems to clash with some of the JavaScript now used in the admin, but I work with those guys now, so I’m working on a new version of the plugin to address those issues! My comments are a bit ugly while I deal with this, but I figure that’s a good motivation to get it done ASAP.

Have you upgraded yet?

Part of add the delete functionality required me to write out the (very, very simple) plugin API for adding and removing tools to the toolbar. I may be a little biased (and not at all modest), but I think it’s pretty cool More about plugins later – but basically webpad 3.0 supports plugins through a “My Plugins” section, so hopefully people might even write some new features for it, allowing access to more external sources of text to edit!

So, I can hear you asking; what’s left? Well:

1. MovableType Support (open, edit, create, delete)
2. WordPress Support (ditto)
3. Update a few interface niceties (like the ‘About webpad’ dialog)
4. Write the new Help Manual, which is a lot different to the last version, and will be a lot bigger
5. Update the webpad project page
6. Fix a scrolling bug in Mozilla (fixed on PC, needs a tweak for Mac)
7. Pretty up some of the error messages
8. Thorough system testing before release
9. Packaging up with some instructions on installation

Oh yeah, and of course, I’m doing the whole dog-food eating thing and as usual, this is posted with the very latest version of webpad (from FireFox), using a couple of the tools and bits and pieces and it’s all looking good.