OpenID and WordPress Core
This was actually a comment I left on my last post about the v3.3 release of the OpenID plugin. It is a topic that comes up relatively often, and one in which most people are surprised when they hear my stance on it. It’s worthy of a separate discussion for those that are interested, so I’ve pulled it out into a separate post.
I’ve talked with core team about this numerous times… in fact, I spoke at WordCamp Portland and Seattle these last two weeks and talked with Matt about it. For the most part, I actually agree with him that OpenID doesn’t necessarily belong in core, at least not yet.
There’s a lot of thought being given to how WordPress can serve as your “digital hub” on the web. Right now, Automattic is playing in that space in the form of BuddyPress. Now right now, BP allows you to create another social network silo. BP installations don’t talk to each other, and there’s no way to use your account on one BP network to login to a different BP network. I talked with Mark Jaquith this weekend about my desire to see this outward facing functionality. For that, I think OpenID becomes painfully obvious.
I would also like to see this OpenID plugin deployed on WordPress.com to replace the existing plugin. Currently, all WP.com blogs are OpenIDs, but you can’t login or leave comments using an external OpenID. And currently, almost no one uses the existing OpenID provider. Of course, I would argue that this is because they haven’t done a good job of promoting it or adding any new features like SReg or AX. Using my OpenID plugin would greatly enhance the OpenID provider functionality on WP.com, and it would allow people to use OpenID when leaving comments. Some of the changes that are included in 3.3 are actually steps toward cleaning up the plugin so that it is more suitable for deploying on WordPress.com. There’s still more work to be done on this front, but it’s something I intend to continue pursuing.
As for inclusion in WordPress core, I just don’t think we’re there yet. The OpenID plugin is pretty popular, but it is far from having the critical mass that would justify inclusion in core. I am a firm believer that WordPress should by no means try and include every cool feature under the sun in core. It would quickly grow out of control. I do believe, however, that the appropriate hooks should be provided in core to allow any cool feature under the sun to be added as a plugin. The core dev team agrees with me on this, and they’ve been very good about making whatever changes were necessary to allow plugins to provide that functionality. In fact, I overhauled how the authentication system is extended in WordPress 2.8 simply to make things like OpenID and OAuth much easier to implement.
A few other things I’d want to see fixed before considering inclusion in core… the OpenID plugin weighs in at what? almost 900K? Remove the screenshots and readme.txt and you’ve got 700K left. Over 500K of that is the JanRain OpenID library. So size is an issue. Also, the biggest problem that people have with getting the plugin to work is related to their environment. WordPress is known for having a very minimal set of requirements to get it running. I’d really want to track down and fix a lot of these weird environment issues that continue to plague the plugin. Finally, we need a really solid UI, both comment form integration and the admin side. I’m pretty happy with the new comment form integration, but the current admin screens need work. More than anything, there is just a lot of functionality in the plugin and it’s hard to boil it down. Especially when you consider both the OpenID consumer and provider options, both site-wide and per-user.
Comments and responses
Buddy Press actually has the goal to bake in the open stack a few iterations down the road: http://buddypress.org/about/roadmap/ (that would be 1.4)
I do think it makes more sense to have it part of Word Press's core, but the adoption of OpenID (et. al.) does seem to be taking it's time.
Part of me wonders if we need to find a way to port activity streams first widely, and then piggy back the rest of the stack on that, but I digress, not knowing enough...
Being a fan of modular software design, I believe this should never go into core. The plugin might get packaged with core, but nothing more.
I was a huge fan of the laconi.ca decision to plugin-ify most of their previously "core" functions because, well, it's just a good idea.
@Stephen, modular software design comes with the right judgement on what to include on core and what not. You could completely modularize WordPress, for example. But, do you really want to do that?
I really can care less about BuddyPress. For me, it is junk. Now, if BuddyPress having OpenID at it's core will help bring it to WordPress... hurray BuddyPress!
a) I'm really glad to see 3.3 out. Thanks so much for fixing the issue with improper sreg retrieval. I tried to fix it on my own, but my lack of coding skills provided several fruitless hours of trying.
b) I would love to see OpenID get to the point of being so ubiquitous that it is fitting for core. In the current state, I think you're right though.
c) one thing still missing from the openid standard is avatar support. gravatar is nice because everyone uses it, but it gives a third party too much information for those of us who want to host openid on our own server. pavatar is my favorite implementation so far, but no one uses it. it would be nice to see a simple line of code added to the sreg standard with a link to an avatar. seems like that would be just as easy to check at login as it is to check for a gravatar image.
d) this is pretty unrelated, but how on earth did you manipulate the widget code so that the little openid icon in the recent posts doesn't get mixed in with the name of the poster? if you see my blog you'll know what i'm talking about.
@Lloyd just like I believe there are features that don't necessarily belong in WordPress core, there are features I don't believe belong in the core OpenID plugin. In fact, the last release dropped support for two such technologies, EAUT and IDIB. The plugin however is designed to be extensible, so support for those, and any other extensions (like pavatar), should be able to be added as separate plugins. Right now, pavatar has nothing to do with OpenID directly, so it wouldn't belong in the OpenID plugin anyway. It is very unlikely that avatar support would be added to SReg... it's pretty well frozen. Attribute Exchange on the other hand is another matter... in fact there are already a few image attributes defined at http://www.axschema.org/types/.
As for your last question, the secret lies here. It's ugly, but it works. It will be in the next release, or you can just grab the latest comments.php from trunk.
I never realized until now that sreg was not a core part of OpenID. My only real understanding of openid came from installing and configuring phpmyid, which is what i used prior to finding your wordpress plugin. I'd never even heard of AX until i read this post.
I knew pavatar was not connected with openID, i just always wished it was because i like the idea of hosting my own image and not having to check in with another server. the one wordpress plugin i ever found that enabled pavatar was identikit. It had some bugs though, and I am not competent enough with php to fix them. In any case, if any openid extension allows for linking to an avatar anywhere, and the consumer sites will support it, i'm on board with that.
Finally, thanks for the assistance with the widgit code. I never would have found that, and I sure never would have figured out how to do that on my own.