MantisBT - Piwigo
View Issue Details
0001682Piwigousers & groupspublic2010.05.24 00:522010.05.24 13:14
plg 
plg 
normalmajoralways
closedfixed 
2.1.0 
2.1.12.1.1 
any
Apache 1.3.x
0001682: fails to create Piwigo user infos with external authentication
It seems quite a specific issue, but I've encountered it, not with external authentication, but after that register.php failed to insert the user_infos line.

Piwigo goes completely blocked for the given user.
No tags attached.
Issue History
2010.05.24 00:52plgNew Issue
2010.05.24 00:52plgStatusnew => assigned
2010.05.24 00:52plgAssigned To => plg
2010.05.24 00:52plgbrowser => any
2010.05.24 00:52plgWeb server => Apache 1.3.x
2010.05.24 01:33plgNote Added: 0003898
2010.05.24 01:33plgNote Added: 0003899
2010.05.24 01:35plgStatusassigned => closed
2010.05.24 01:35plgResolutionopen => fixed
2010.05.24 01:35plgFixed in Version => 2.1.1
2010.05.24 01:45plgNote Added: 0003904
2010.05.24 13:12svnCheckin
2010.05.24 13:12svnNote Added: 0003908
2010.05.24 13:14svnCheckin
2010.05.24 13:14svnNote Added: 0003909

Notes
(0003898)
plg   
2010.05.24 01:33   
[Subversion] r6312 by plg on branch 2.1

-----[Subversion commit log]----------------------------------------------------
bug 1684 fixed: the test to check availability of the user_infos line was
wrong. I had changed the old db_num_rows > 0 because it was not working with
SQLite. As suggested by nicolas, let's use a simpler trick "count(1)" in the
query itself, this way it should work with any database engine.

I've also removed the while (true) (ugly infinite loop, with a condition for
exit) that was producing an infinite loop for Piwigo installations with 2.0
database model and 2.1 code (before launching upgrade.php)
(0003899)
plg   
2010.05.24 01:33   
Oups... the [Subversion] r6312 fixes 0001682 not 0001684
(0003904)
plg   
2010.05.24 01:45   
[Subversion] r6315 by plg on trunk

-----[Subversion commit log]----------------------------------------------------
merge r6312 from branch 2.1 to trunk

bug 1684 fixed: the test to check availability of the user_infos line was
wrong. I had changed the old db_num_rows > 0 because it was not working with
SQLite. As suggested by nicolas, let's use a simpler trick "count(1)" in the
query itself, this way it should work with any database engine.

I've also removed the while (true) (ugly infinite loop, with a condition for
exit) that was producing an infinite loop for Piwigo installations with 2.0
database model and 2.1 code (before launching upgrade.php)
(0003908)
svn   
2010.05.24 13:12   
[Subversion] r6321 by plg on branch 2.1

-----[Subversion commit log]----------------------------------------------------
bug 1682: r6312 was producing a MySQL error (depending on the MySQL server
version) because a count() implies a group by.

This code change was checked against MySQL 5.0.75, MySQL 5.0.51 (where the
error occured) and SQLite 3.6.22.
(0003909)
svn   
2010.05.24 13:14   
[Subversion] r6322 by plg on trunk

-----[Subversion commit log]----------------------------------------------------
merge r6321 from branch 2.1 to trunk

bug 1682: r6312 was producing a MySQL error (depending on the MySQL server
version) because a count() implies a group by.

This code change was checked against MySQL 5.0.75, MySQL 5.0.51 (where the
error occured) and SQLite 3.6.22.