OpenID for WP 2.7

That version works fine on my 2.7 blog.

Have you tried it and experienced problems?

I had problems with redirecting back to site after accepting it.
Redirect not working, just showing blank page.
Using 3.1.4 on 2.7

Redirect not working, just showing blank page.

Do you have access to your server’s error_log? If you can reproduce the error, and it tosses a message in the log then post it here.

That plugin’s author is very responsive on this forum.

give version 3.2 a shot (just released yesterday). Of course, there’s no guarantee that it’ll fix your issue, but there were quite a few bug fixes in this release.

I had the same problem, but then it started working. I did a few things along the way, including deactivating/reactivating the plugin, and editing and saving the settings. I’m guessing it was one of those things that did the trick.

I’m having issues… I disabled the provider so I can use my own local provider and manually put the <link rel’s in, but now the XRDS is returning the consumer urls as /openid/consumer – which that folder just has my few files for my provider (phpMyID) and is not going to the /wp-content/plugins/openid/ folder.

How can I fix this?

I fixed my problem, the plugins code requires that an openid folder not exists to rely on Friendly URLs, so a simple comment out of the check and always use /index.php/openid/consumer fixed the issue.

Plugin author: you should prolly remove that officially and always go through index.php to avoid this problem in future. By me having an openid folder broke the login procedure.

common.php line 860

if ($wp_rewrite->using_permalinks()) {
		//if ($wp_rewrite->using_index_permalinks()) {
			$url .= 'index.php/';
		//}

Aiker: so this actually should work as is… I’ve tested it with all kinds of different permalink structures. What do you have set on your permalink settings page in WordPress? What web server is your website running on? (Apache, Lighttpd, Microsoft IIS, other)

If you don’t mind, what is your website URL so I can look at it myself?

Aiker: read back over your comment and finally understood the problem you were describing. You’re absolutely right, the plugin will have problems if there is a folder named ‘openid’ in the same directory as wordpress.

I would strongly suggest moving wordpress out of your site’s root directory and into a separate “wordpress” directory. You can then setup “WordPress Address” and “Blog Address” options to make this change invisible. You can see this kind of setup on my site… My website is at willnorris.com, but I have wordpress in a separate directory.

Once you’ve moved your wordpress directory, your other ‘openid’ directory won’t be conflicting with the plugin anymore. This also really cleans up your site root, making things a bit more organized.

I don’t want it outside of root lol, plus it wouldnt change the problem, as the htaccess see’s the openid directory and accesses it instead of sending it to the index.php, so unless all urls went to /wp/blah, problem would still exists.

Making the modification above and simply making it always pipe through index.php fixes the problem.

This shouldn’t matter considering this isn’t something search engines will be hitting (I don’t know of any search engines that will be logging in with openid’s into sites…), and the redirects are fast so you don’t even notice the urls including index.php nor is it something you would bookmark… so it really doesn’t hurt anything to not use friendly urls for this stuff to maximize compatibility with everyone’s site.

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.

I have a slightly different problem. When i try to login using my blog URL as an OpenID, result is blank page with “This is an OpenID server”. No redirect back to site, and no login on it at all.

I’am using WP 2.7.1, OpenID 3.2.1 on lighttpd with FastCGI and permalinks enabled.

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.

Now it’s up and running.
Unfortunately I can not say were was problem, as I updated bath of plugins. It’s works with 2.7.1 and up ??