Hello,
the website i am trying to develop is www.homies.gr/d5.
I have installed the openid module but when i click on login with openid
it just shows the button login but not the form which i have to put the
openid username.
Thanks in advance

CommentFileSizeAuthor
#10 378178_openidbox.patch570 bytesanarcat

Comments

Leeteq’s picture

I have seen the same behaviour on a site running Drupal 5.12.

passa’s picture

I've got the same things too .....

Leeteq’s picture

Title: OpenID form field not showing » form not showing
Priority: Critical » Normal

FYI
- does not work on a site running OpenID 1.2, JQuery_update 2.0 and Drupal 5.15
- works well on an old site running OpenID 1.2, JQuery_update 1.0 and Drupal 5.7

Edit:
- I have tested this on older sites with no other modules than OpenID, with and without JQuery_update, and it works well on Drupal core 5.7 and 5.9 both with JQuery_update1.0 and 2.0 (but not without JQuery_update) I have not tested on 5.10/11/12/13.
- it does not seem to work on Drupal 5.14 or 5.15, regardless of JQuery_update version.

Hmmm. If this is a general problem related to Drupal core, then it seems puzzling why this issue has not been given greater attention of more people up until now? Then many sites must have this problem, or people simply does not bother using OpenID on D5x, or many have not updated past 5.9?

Edit2:
- I did actually test on Drupal 5.12 too, with JQuery 1.2.6 (JQuery_Update.module v 2.0), which did NOT work.
- for the configurations that worked, all of them was only tested against Yahoo, did not worked against Blogger/Google Account (not tested them all against it). I have not yet used the patch here, though: "[PATCH] Blogger Authentication Fix (OpenID 1.1 server compatibility)" (Current version is unable to authenticate with 1.1 servers), http://drupal.org/node/233885
- next: will try with the newly released Drupal 5.16 later today.

Leeteq’s picture

Title: form not showing » OpenID form field not showing
Priority: Normal » Critical

A temporary workaround could be not using JavaScript and thus show the OpenID login field by default.

Most sites supporting (and promoting) OpenID actually display the OpenID field by default, and I
think that is the most desireable situation anyway.

- is that a fairly easy code adjustment?

Aside of that, modules should "gracefully degrade" anyway, and that degrading effect could perhaps be a configuration option, so that even with JS enabled, it could be set to not use JS...

Edit:
This is already reported as a feature request here:

"Using OpenID without Javascript"
http://drupal.org/node/231063

Berto’s picture

Title: form not showing » OpenID form field not showing
Priority: Normal » Critical

Same thing here, using Drupal 5.16. At first, I had the original version of jQuery, then I upgraded mine using jQuery_Update and get the same thing. What's happening here?

I also agree that I'd rather have the OpenID field be the default login field (or at least have the option to see this as default)

anarcat’s picture

Another "me too" here, Drupal 5.16, OpenID 1.2.

anarcat’s picture

Using the following stylesheet block makes it so that the openid field shows by default:

html.js #user-login-form div#edit-openid-identifier-wrapper,
html.js #user-login div#edit-openid-identifier-wrapper {
display: block;
}

Then clicking the link properly hides and shows the field, so I don't know what's going on here...

anarcat’s picture

Status: Active » Needs review

This is very weird: there are two divs with the id #edit-openid-identifier-wrapper

<div><div id="edit-openid-identifier-wrapper"><div class="form-item" id="edit-openid-identifier-wrapper">
 <label for="edit-openid-identifier">Ouvrir une session OpenID : </label>
 <input type="text" maxlength="255" name="openid_identifier" id="edit-openid-identifier"  size="58" value="" class="form-text" />
[...]
</div>
</div>

with firebug, I was able to workaround the bug by renaming the second one. I have *no* idea where the heck this second item is coming from. However, just commenting out the prefix/suffix lines do fix this issue:

--- openid.module.orig  2009-03-17 17:45:20.000000000 -0400
+++ openid.module       2009-03-17 17:45:23.000000000 -0400
@@ -103,8 +103,8 @@
       '#maxlength' => 255,
       '#weight' => -1,
       '#description' => l(t('What is OpenID?'), 'http://openid.net/'),
-      '#prefix' => '<div id="edit-openid-identifier-wrapper">',
-      '#suffix' => '</div>'      
+      #'#prefix' => '<div id="edit-openid-identifier-wrapper">',
+      #'#suffix' => '</div>'      
       );
     $form['openid.return_to'] = array('#type' => 'hidden', '#value' => url('openid/authenticate', drupal_get_destination(), NULL, TRUE));
     $form['name']['#prefix'] = '<div id="edit-name-wrapper">';

This is so weird that I'm not bothering writing a real patch for now, i'd like feedback at this point.

Berto’s picture

Thanks anarcat!

Just for giggles, I commented out the prefix and suffix as you propose, then changed EVERY mention of identifier, including the form, to "ientifier" (except the line that says $identity = 'http://specs.openid.net/auth/2.0/identifier_select';)

Upon clearing the cache, I get BOTH login boxes, but all mentions of identifier are gone:

<div><div class="form-item" id="edit-openid-ientifier-wrapper">
 <label for="edit-openid-ientifier">Log in using OpenID: </label>
 <input type="text" maxlength="255" name="openid_ientifier" id="edit-openid-ientifier"  size="13" value="" class="form-text" />
 <div class="description"><a href="http://openid.net/">What is OpenID?</a></div>
</div>
<div id="edit-name-wrapper"><div class="form-item" id="edit-name-wrapper">
 <label for="edit-name">Username: <span class="form-required" title="This field is required.">*</span></label>

 <input type="text" maxlength="60" name="name" id="edit-name"  size="15" value="" class="form-text required" />
</div>
</div><div id="edit-pass-wrapper"><div class="form-item" id="edit-pass-wrapper">
 <label for="edit-pass">Password: <span class="form-required" title="This field is required.">*</span></label>
 <input type="password" name="pass" id="edit-pass"  maxlength="60"  size="15"  class="form-text required" />
</div>
</div><input type="submit" name="op" id="edit-submit" value="Log in"  class="form-submit" />

I really don't see why that suffix and prefix are in there. It must have been a workaround based upon a past jquery+drupal bug that is now fixed.

Or a better guess is that Drupal itself is looking at the name of the form, and creating those 'edit-openid-identifier' boxes all on its own now. It does this automatically with forms. So no more need for this suffix/prefix business.

The reason I get both login boxes now is that openid.css can't find and hide the 'edit-openid-identifier', so I'll be going back to the old name.

Not sure when drupal changed its form / div naming scheme, but that seems to be the reason.

anarcat’s picture

StatusFileSize
new570 bytes

So I tried something: I removed the patch, cleared the cache, and logged out. Now it's broken again (ie. the openid form doesn't appear when clicking the openid link). I reapplied the patch and cleared the cache, problem still there.

So it's not just a cache issue. ie. after clearing the cache, the problem is still there (double <div>s named edit-openid-identifier-wrapper).

This looks like a Forms API compatibility issue of some sort: at some point, the openid.module felt it had to add that wrapper. Now, the forms API does it by itself, so the wrapper isn't necessary.

I simply propose removing the wrapper, that fixes the bug for me. Patch attached.

emackn’s picture

Adding

html.js #user-login div#edit-openid-identifier-wrapper.form-item { display:block; }

to my theme stylesheet fixed this for me.

emackn’s picture

This css tweak has worked on all the drupal 5 installs using OpenID that I have been maintaining.

The one exception I have found is that issues crop up when the login "page" has a login "block" displaying.

yhahn’s picture

Assigned: Unassigned » yhahn
Status: Needs review » Reviewed & tested by the community

anarcat's patch on comment #10 works great and is the right way to solve this problem.

Setting to RTBC.

anarcat’s picture

So what's up? A release went through without this critical (i understand it was for a security issue...). When will this patch (working fine for months here) be committed and shipped in a release?

vitozzo’s picture

The patch on comment #10 worked like a charm for me, it should really be included in the next release of the module.