Will Norris

I really like reCaptcha (as far as captchas go) so I looked at how I could modify wp-openid to make this possible. Unfortunately, it’s a bit tricky. The problem is that comment hooks don’t get called until after the OpenID redirect stuff has happened. By the time they get called, the original reCaptcha data that was posted is no longer available. I can’t simply store this data temporarily and then recover it since the reCaptcha plugin is looking directly in the $_POST array for the data. This is not a unique problem to reCaptcha… it should actually cause problems with any plugin that causes additional data to be posted as part of a comment submission. The best solution will likely be for wp-openid to use immediate authentication when available, which would prevent the whole redirect from being necessary at all. This would be limited to OpenID 2.0 providers, but should solve the problem. I’ll definitely see about adding that in when I get the chance.

see if this helps… https://willnorris.com/2007/12/rebuild-wp-openid-tables

for anyone still have trouble with this… try https://willnorris.com/2007/12/rebuild-wp-openid-tables

fixed this today: https://dev.wp-plugins.org/ticket/729

yep… doesn’t look like WP uses the notes field that I can tell.

I know this is old, but I am in need of similar functionality. What I believe the original poster was requesting was some way to store the comment content just in case something goes wrong with submitting the comment. For example, if the blog requires name and password and I don’t provide them. When I go back in my browser, my comment is often lost. In my particular case, my plugin allows OpenID to be used for authentication. If that authentication fails for whatever reason, the comment is lost.

The easiest solution would be to store the content in a browser cookie or PHP session, and then restore the textarea content when they return to the page. Ideally, this should be core functionality for WordPress due to the require name/email option in WP.

hmm.. I made a couple of udpates. Try replacing your logic.php with the one here… https://svn.wp-plugins.org/openid/trunk/logic.php

no, it’s not your OpenID provider (in this case MyOpenID)… it’s your webhost (DreamHost). They likely have an old version of the ca certs file.

it’s basically saying that the tables didn’t get created properly. Most of the time, you can simply disable the plugin and then re-enable it once or twice which will force it to rebuild the database tables, so try that first. I’ve run into a few cases where it takes more than that so let me know if you still have trouble.

sairuh… just remember what is probably wrong. Check the “https” question in the FAQ for wp-openid. I bet that’s your problem. You can either try the solution linked to in that FAQ, or just delegate to non-https URLs. The reason you were able to use your delegated OpenID on my site is because I contacted Joyent and had them update that ca cert file.

see if version 1.2.1 works better for you.

I replied to your bug report at https://dev.wp-plugins.org/ticket/718

I can tell by the filename (openid-registration.php) you were using a *very* old version of the plugin. I just tagged 2.0, so give that a shot.

I’ve just release version 2.0, so it should just be plug and play at this point.

heh.. I can’t recall what all has changed since the last released version. I’ll have to look into that.