I noticed that on one of my sites, the "OpenID Selector for Drupal login" was not working.

It seems that this was caused by the order in which JS files were added to the page. On the non-working site, I had:

<script type="text/javascript" src="/sites/all/modules/openid_selector/openid_selector_drupal.js?l"></script>
<script type="text/javascript" src="/sites/all/libraries/openid-selector/js/openid-jquery.js?l"></script>
<script type="text/javascript" src="/sites/all/libraries/openid-selector/js/openid-jquery-en.js?l"></script>
<script type="text/javascript" src="/sites/all/modules/openid_selector/openid_selector.js?l"></script>

Solved this by setting the weight of openid_selector_drupal to 1.

Afterwards, I noticed that I also needed to set the weight of openid_selector_twitter to 1 on that site, otherwise the twitter icon would not show up...

... so here's .install files for all modules except the main one. This is one way of solving things. (Maybe there is also another one...)

CommentFileSizeAuthor
openid_selector_installs.zip3.56 KBroderik

Comments

andriy_gerasika’s picture

andriy_gerasika commented

this is quite weird:
openid_selector_drupal depends on openid_selector which depends on openid

hence logically the order should be:
openid, openid_selector, openid_selector_drupal

Can you post URL of the website w/ wrong order? (curious why it happens)

andriy_gerasika’s picture

andriy_gerasika commented

actually Drupal module hooks are executed using weight and filename order -- openid_selector filename is before openid_selector_drupal filename, so theoretically this should not happening

can you please attach results of 

SELECT * 
FROM system
ORDER BY  `filename` ASC
roderik’s picture

roderik
Primary language Dutch
Location Amsterdam,NL / Budapest,HU
commented

Oh, no...

Here's a fragment of the 'SELECT name, filename FROM system ORDER BY filename ASC' on the offending system...

 openid_selector_drupal                | sites/all/modules/openid_selector/openid_selector_drupal.module
 openid_selector_fbconnect             | sites/all/modules/openid_selector/openid_selector_fbconnect.module
 openid_selector_fb                    | sites/all/modules/openid_selector/openid_selector_fb.module
 openid_selector_inline                | sites/all/modules/openid_selector/openid_selector_inline.module
 openid_selector_linkedin              | sites/all/modules/openid_selector/openid_selector_linkedin.module
 openid_selector_mailru                | sites/all/modules/openid_selector/openid_selector_mailru.module
 openid_selector                       | sites/all/modules/openid_selector/openid_selector.module
 openid_selector_twitter               | sites/all/modules/openid_selector/openid_selector_twitter.module
 openid_selector_vkontakte             | sites/all/modules/openid_selector/openid_selector_vkontakte.module
 openid_selector_winliveid             | sites/all/modules/openid_selector/openid_selector_winliveid.module

The collation is 'wrong'. Underscore and period seem to have the same 'weight'.

This is a database with charset UTF8 (afaik) on PostgreSQL 8.3. I am still using 8.3 on my live server because that is included with the current Debian stable (lenny).
On my development machine I have PostgreSQL 8.4 (and I thought I created a database with the same collation...) and there, the ordering is 'correct', i.e. not as above.

So, I guess this does not qualify as something that has to be solved in the module.

P.S. I guess I remembered wrong, in my original bug report. I said the Twitter icon didn't show up, but it was the LinkedIn icon that didn't show up. Figures.

roderik’s picture

roderik
Primary language Dutch
Location Amsterdam,NL / Budapest,HU
commented
Status: Needs review » Closed (works as designed)

Well. it's not the PostgreSQL version that makes the difference... it must be something else on my live server, or the specific database...

(I just upgraded my PostgreSQL cluster from 8.3 to 8.4 with standard debian scripts. And the sort order is still wrong - unlike on my development laptop.
'show all' reports "en_US.UTF-8" as the default collation for the server. This is all I know to find.)

Let's forget about it. Thank you for the hint / looking at it.

andriy_gerasika’s picture

andriy_gerasika commented

what encoding does phpPgAdmin display? I was not testing OpenID Selector on anything else except unicode_general_ci

roderik’s picture

roderik
Primary language Dutch
Location Amsterdam,NL / Budapest,HU
commented

I admit to being a bit of an amateur in postgres... just running two personal sites on it...

*installs phppgadmin*
If I look under 'variables', the 'client_encoding' and 'server_encoding' show as "UTF8". On both my (faulty) Debian VPS (Xen DomU) and my (correct) MacBook.

Actually, I do not see any variable which should matter, that is set differently :-[

andriy_gerasika’s picture

andriy_gerasika commented
Status: Closed (works as designed) » Active

I have installed PostgreSQL, created simple table and simple select * from test order by name produces:

"a_a"
"a.a"
"a_b"
"a.b"

confirmed:
current version of OpenID Selector is not working under PostgreSQL

thanks for bringing this up

andriy_gerasika’s picture

andriy_gerasika commented
Status: Active » Fixed

fixed in http://drupal.org/cvs?commit=479462

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.