Piwigo Bugtracker

Viewing Issue Advanced Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0000397 [Piwigo] synchronization block always 2006.06.02 10:57 2006.07.04 00:51
Reporter juSt View Status public  
Assigned To plg
Priority normal Resolution fixed Platform
Status closed   OS
Projection none   OS Version
ETA none Fixed in Version 1.6.0RC3 Product Version 1.6.0RC1
  Target Version Product Build
Summary 0000397: Column 'uploadable' cannot be null
Description J'ai ce problème lorsque je tente de synchroniser mon espace free avec celui de plebia. Quand je simule ça passe, quand je décoche simuler voici ce que ça met :


INSERT INTO phpwebgallery_categories
  (id,dir,name,site_id,id_uppercat,uppercats,commentable,uploadable,visible,status,rank,global_rank)
   VALUES
  ('13','amis','amis','2',NULL,'13','true',NULL,'true','public','3','3')
;
[mysql error 1048] Column 'uploadable' cannot be null
Steps To Reproduce
Additional Information
Tags No tags attached.
browser Mozilla
Database engine and version
PHP version
Web server Apache 1.3.x
Attached Files

- Relationships

-  Notes
(0000997)
plg (manager)
2006.06.02 22:30

Après une bonne demi-heure de recherche, je pense avoir trouvé le problème, c'est une histoire de type de variable et de mode de comparaison je pense. Peux-tu faire le test suivant : dans admin/include/functions.php, ligne 611 remplace

if (!isset($insert[$dbfield]) or $insert[$dbfield] == '')

par

if (!isset($insert[$dbfield]) or $insert[$dbfield] === '')

(un simple signe "=" à ajouter) et me dire si ça corrige bien le problème ?
(0001002)
juSt (reporter)
2006.06.02 23:16

Ca marche !

Merci !
(0001005)
plg (manager)
2006.06.02 23:46

Je reste encore sur un sentiment amer d'incompréhension. En effet, dans admin/site_update.php, on passe une chaîne de caractère pour le champ "uploadable" et pas un booléen. Dans mes tests en local, j'ai simulé le site distant et cela fonctionne très bien.

Bref, j'attends encore un peu avant de commiter la modification que tu as testé avec succès.
(0001014)
mathiasm (manager)
2006.06.03 23:42

est-ce que ça peut venir de ce comportement: http://fr2.php.net/manual/fr/language.operators.comparison.php#43754 [^]

A priori, le double égal fait de la conversion de types.
(0001164)
plg (manager)
2006.07.04 00:51

- corrigé en branche 1.6 [Subversion] r1427
- reporté sur trunk [Subversion] r1428

J'ai donc pris la solution de l'opérateur "===", mais je ne comprends pas vraiment pourquoi c'est utile dans le cas présent.

- Issue History
Date Modified Username Field Change
2006.06.02 10:57 juSt New Issue
2006.06.02 10:57 juSt browser => Mozilla
2006.06.02 10:57 juSt Web server => Apache 1.3.x
2006.06.02 22:30 plg Note Added: 0000997
2006.06.02 22:30 plg Assigned To => plg
2006.06.02 22:30 plg Severity minor => block
2006.06.02 22:30 plg Status new => assigned
2006.06.02 22:30 plg Category upload management => directories update
2006.06.02 22:30 plg Platform on plebia.org =>
2006.06.02 22:37 plg Status assigned => feedback
2006.06.02 23:15 juSt Issue Monitored: juSt
2006.06.02 23:15 juSt Issue End Monitor: juSt
2006.06.02 23:16 juSt Note Added: 0001002
2006.06.02 23:46 plg Note Added: 0001005
2006.06.02 23:48 plg Status feedback => assigned
2006.06.03 23:42 mathiasm Note Added: 0001014
2006.07.04 00:51 plg Note Added: 0001164
2006.07.04 00:51 plg Status assigned => closed
2006.07.04 00:51 plg Resolution open => fixed
2006.07.04 00:51 plg Fixed in Version => 1.6.0RC3


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Contact
Powered by Mantis Bugtracker