Je viens de trouver un bug sur la branche 2.0
J'ai des pelletées de çà quand je consulte une catégorie :
Notice: Undefined offset: 1 in /home/e-smith/files/ibays/testpwg20x/html/include/functions.inc.php on line 604 Notice: Undefined offset: 2 in /home/e-smith/files/ibays/testpwg20x/html/include/functions.inc.php on line 604 Notice: Undefined offset: 3 in /home/e-smith/files/ibays/testpwg20x/html/include/functions.inc.php on line 604 Notice: Undefined offset: 4 in /home/e-smith/files/ibays/testpwg20x/html/include/functions.inc.php on line 604 Notice: Undefined offset: 5 in /home/e-smith/files/ibays/testpwg20x/html/include/functions.inc.php on line 604 Notice: Undefined offset: 6 in /home/e-smith/files/ibays/testpwg20x/html/include/functions.inc.php on line 604 Notice: Undefined offset: 0 in /home/e-smith/files/ibays/testpwg20x/html/include/functions.inc.php on line 617
Le problème : la fonction format_date ne gère pas correctement les dates de type "mysql_datetime" si l'heure est omise dans le format. Hors cette fonction appellée deux fois en précisant le type 'mysql_datetime' et en fournissant des dates au type de format 'us' (j'ai référencé le bug dans mantis [Bugtracker] ticket 900)
Là ou j'ai mis du temps à comprendre, c'est pourquoi je n'avais pas le problème sur la trunk, étant donné que le code est le même. En fait, j'ai des plugins en cours de dev sur la branche 2.0 et j'ai activé les warnings et autres affichages d'erreurs. En regardant les logs sur le serveur apache, je constate bien que le même problème est présent sur la trunk (ce qui est quelque part rassurant).
Ma question : ne devrait-on pas, pour les RC, activer l'affichage des warnings ?? çà permettrait à tout le monde de voir ce genre de choses, et çà permettrait d'éliminer plus de bugs.
Hors ligne
Moi, aussi, je me suis demandé quoi hier soir!
J'étais entrain de tester la migration en local de ma galerie de prod et je pensais que c'était lié.
J'avais aussi identifié que ca venait d'un champs date (et pas datetime) de mysql...
C'est en voyant ton commit, que j'ai compris que ca venait du commit de vdigital 2840
New: Extend of available fields within a category page for a template-extension simple usage. Refer to topic: "Smoothgallery plugin" where no plugin is requested to do it.
Plutot que de mettre 'us' comme tu l'as fait dans le commit 2850, on ne pourrait pas créer un nouveau type 'mysql_date'?
Hors ligne
Je suis sur thème du forum...
Si tu peux corriger mon erreur.
Merci rub.
8-)
Hors ligne
grum l'a déjà fait!
Mais, je vais mettre un nouveau type, ca sera plus clair...
Hors ligne
done
Hors ligne
Merci à tous les deux.
8-)
Hors ligne
grum a écrit:
Ma question : ne devrait-on pas, pour les RC, activer l'affichage des warnings ?? çà permettrait à tout le monde de voir ce genre de choses, et çà permettrait d'éliminer plus de bugs.
Tu as tout à fait raison. Tu peux déjà commiter ça sur trunk/branch 2.0 (E_ALL, c'est très bien à mon avis). J'ajoute ça dans la liste des trucs à désactiver quand on fait une release "stable". Il faut que ce soit désactivable par un paramètre de configuration si possible.
Hors ligne
dans le fichier de config, rangé avec les paramètres pour le debug : $conf['show_php_errors'] = E_ALL;
avec, juste après l'include du fichier de config, un ini_set avec le paramètre s'il est renseigné.
si la solution convient je peux faire un commit.
Hors ligne
C'est bien ce qu'il faut faire, aucun doute.
8-)
Hors ligne
grum a écrit:
dans le fichier de config, rangé avec les paramètres pour le debug : $conf['show_php_errors'] = E_ALL;
avec, juste après l'include du fichier de config, un ini_set avec le paramètre s'il est renseigné.
si la solution convient je peux faire un commit.
Par rapport à ton commit, pour moi le isset n'est pas utile car le empty teste si la variable est affectée ou non.
Ne devrait-on pas utiliser directement la fonction error_reporting? (Même si ca fait pareil que ini_set('error_reporting')
Hors ligne