Will Norris

New user accounts are not created when leaving a comment with an OpenID. If an account already exists, and is connected with that OpenID, then the user is logged in, but new accounts are never created. The plugin used to work this way, but it never made sense to me, so I changed it almost a year and a half ago. See the “create local accounts” bullet point on this post from October 2007.

The only way that a new account is created with an OpenID is if the user explicitly logs in at the wp-login.php page. However, this page also respects whether or not you have enabled new account registration. Even if OpenID is successful, new accounts are never created if you have disabled them by un-checking “anyone can register” on the General Settings page in WordPress.

I’m not able to reproduce the behavior you’re describing: creating new WordPress accounts simply be leaving a comment with an OpenID. However, if this is really happening for you, I would most certainly classify it as a bug and would love to discuss more so I can fix it.

As far as an option to disable the OpenID consumer entirely… that is something I have considered. Initially, the plugin was a consumer only, so that didn’t make sense. Now that it is also an OpenID provider, I guess I can imagine that some users would want to disable the consumer, however I’ve heard very, very little demand for this.

CodeCritic: assuming that your running the latest version of that plugin, it seems to be fine… doesn’t have this problem. That’s not to say that you may not have another plugin that is causing the same problem.

see: https://code.google.com/p/diso/issues/detail?id=26

yes, there is an outstanding ticket for it. I’ve just updated the POT file for the plugin, so feel free to add a translation…

https://code.google.com/p/diso/issues/detail?id=26

try logging in at the test site below, and let me know what it says in the green box at the end (feel free to omit your real email address if present).

https://openidenabled.com/php-openid/trunk/examples/consumer/

fixed in trunk, and will be in the 3.2.2 release. thanks for the patch.

mothlike: there was a problem with non-apache web servers and permalinks. It’s been fixed and will be in the 3.2.2 release.

that’s because that was posted after 3.2.1 was released. It will be in the 3.2.2 release (hopefully later today)

as mentioned on the bug report joanium linked to, this is now fixed in trunk and will be in the 3.2.2 release.

this is very likely a conflict with another WordPress plugin. Try the solutions mentioned here: https://www.ads-software.com/support/topic/243648

this is a problem when using various techniques to get “pretty URLs” with non-Apache web servers. It’s been fixed in trunk and will be in the 3.2.2 release.

You do understand that even though the ‘wordpress’ folder is moved out of the root, that doesn’t mean that you have to go to “yoursite.com/wordpress” to get to your blog, right? You can set it up to still be accessible as “yoursite.com”… it basically just requires copying, and slightly modifying, WordPress’s index.php file.

Just as you’ve described, there is always a potential problem in WordPress of a namespace collision… when you have both a WordPress managed page or artifact that has the same name as a real file or folder on your server. In these cases, the actual file or folder always trumps WordPress, as it rightfully should. By moving WordPress into a separate directory, you create a WordPress-only namespace that doesn’t conflict with your filesystem. If WordPress plugins use this dedicated namespace for administrative type stuff, then you don’t have a conflict.

Now, all that being said… I absolutely understand your point. One other way to eliminate the naming conflict I just mentioned is to use ‘index.php’ in WordPress URLs. I understand that these work just fine in all WordPress installations, and are one way of ensuring the OpenID server URL works on all WordPress blogs regardless of how they are setup. My primary arguments against this:

• It’s certainly a purist standpoint, but this violates the principle of Cool URIs. This alone is certainly not enough to convince me, but is always something to keep in mind.
• This butts heads with WordPress’s internal URL canonicalization code. For example, on one of my development sites, i have “/wordpress/index.php/openid/server” automatically redirect to “/wordpress/openid/server”, because that is what OpenID believes to be the canonical URL, based on my permalink settings. This small redirect may seem minor, but I’ve had problems with other plugins of small redirects like this causing session variables to be lost. Now, I’m sure I can identify what’s causing the data loss, but I still don’t like the idea of trying to fight against WordPress rather than working with it.

I certainly don’t consider this matter closed, and will always look for ways of doing things “The WordPress way” that ensures the plugin works out of the box for as many users as possible. But for the time being, I plan to leave this particular code the way it is right now. At the very least, I’ll see about adding a hook that should make what you’re doing a bit easier, without having to modify core plugin files.

So it looks like you setup the OpenID delegation stuff on zaneselvans.org with a previous version of the plugin, and recently upgraded. I can tell b/c of the OpenID server URL you have on there:
<link rel="openid2.provider" href="https://amateurearthling.org/?openid_server=1" />

If you take a look at what you have on amateurearthling.org, you’ll notice this has been changed to:

<link rel="openid2.provider" href="https://amateurearthling.org/openid/server" />

The delegate URL should also be changed to be your author URL, not the root blog URL. Basically, just copy the exact OpenID delegation stuff you have on amateurearthling.org, and put that on zaneselvans.org:

<link rel="openid2.provider" href="https://amateurearthling.org/openid/server" />
<link rel="openid2.local_id" href="https://amateurearthling.org/author/zane/" />
<link rel="openid.server" href="https://amateurearthling.org/openid/server" />
<link rel="openid.delegate" href="https://amateurearthling.org/author/zane/" />

Yeah, you’re not the only one:

https://code.google.com/p/diso/issues/detail?id=101
https://www.ads-software.com/support/topic/236131
https://www.ads-software.com/support/topic/218421

The vast majority of users aren’t having this problem, but for some reason a decent sized handful of people are. I was able to fix this for some people in the version 3.2.1 release of the plugin, but apparently there are still some edge cases out there I haven’t been able to track down yet.

If you already have a spam question on your comment form, then that OpenID option probably won’t do much for you.

The idea with that option was that down the road, the plugin could support different kinds of comment approval mechanisms. For example, some people have asked about only accepting OpenID comments from a select list of OpenID providers. That would hook into the OpenID plugin in the same place as the above option.