Bonjour aux développeurs d'extensions, notamment aux créateurs de plugins
Dans Piwigo 2.5, Mistic100 a implémenté la nouvelle librairie mysql appelée MySQLi, en complément de l'actuel classique mysql. Par défaut, Piwigo chargera MySQLi si elle est disponible.
Deux problèmes de compatibilité ont été soulevés :
1) les fonctions mysql_* ne fonctionnent plus
Avec MySQLi les fonctions du type mysql_* ne fonctionneront plus. Elles doivent toutes êtres remplacées par leur équivalent pwg_db_* :
mysql_query => pwg_query
mysql_fetch_row => pwg_db_fetch_row
mysql_fetch_assoc => pwg_db_fetch_assoc
mysql_insert_id => pwg_db_insert_id
mysql_num_rows => pwg_db_num_row
mysql_real_escape_string => pwg_db_real_escape_string
En parlant d'habitudes de façon de coder, je me permet de rappeler cette note [Forum, topic 23485] [maj] Msg aux créateurs de plugin qui ajoutent une page index.php/xxx
2) mysql_fetch_array
Malheureusement, pwg_db_fetch_array n'existe pas dans Piwigo 2.4 et précédent , contrairement aux autres fonctions pwg_db_*.
pwg_db_fetch_array a été ajouté en 2.5, donc vous pouvez désormais changer mysql_fetch_array par pwg_db_fetch_array, tout simplement. Cependant, votre extension ne sera plus compatible 2.5 !
Si vous souhaiter être compatible 2.5, conserver la compatibilité 2.4 et avoir un meilleur code, il est préférable de remplacer par pwg_db_fetch_assoc ou pwg_db_fetch_row. Par ex soit le code suivant :
$query = ' SELECT id, name FROM '.IMAGES_TABLE.' ;'; $result = pwg_query($query); while ($ligne = mysql_fetch_array($result)) { // qu'avons nous dans $ligne ? // $ligne[0] == $ligne['id'] // $ligne[1] == $ligne['nom'] }
Il est très probable que vous n'utilisiez que des array associatifs $ligne['id'] et que vous n'allez jamais utiliser $ligne[0], $ligne[1].
Avec pwg_db_fetch_row vous n'obtenez que $ligne[0] et $ligne[1]
Avec pwg_db_fetch_assoc vous n'obtenez que$ligne['id'] et $ligne['nom']
Donc selon votre code, utilisez préférentiellement pwg_db_fetch_row ou pwg_db_fetch_assoc, plutôt que pwg_db_fetch_array
Merci pour votre attention. La liste complète des changements techniques est disponible en anglais ici http://piwigo.org/doc/doku.php?id=dev:changes_in_2.5 (index.tpl, Jquery ui effects, comment_list.tpl, picture.tpl, nouvelles icones et méthodes possibles...)
Dernière modification par flop25 (2013-02-27 16:12:29)
Hors ligne
Bonjour,
Cette modification me pose quelques soucis avec mes plugins.
OK pour l'usage des fonctions pwg_db_* / pwg_* et j'ai bien pris en compte le pb de mysql_fetch_array. Par contre, j'utilise aussi mysql_error() et mysql_num_fields().
Je pense que le premier peut être remplacé par la fonction my_error() de Piwigo. Mais mysql_num_fields() n'est pas du tout pris en charge. Le remplacer par mysqli_num_fields() serait une erreur car imposerait Mysqli même si l'extension n'est pas présente.
J'utilise mysql_num_fields() notamment pour compter le nombre de champs composant une table afin de créer un dump Sql. Par exemple :
$req_table = pwg_query('SELECT * FROM '.$ListTables[$j]) or die(my_error()); $nb_fields = mysqli_num_fields($req_table); while ($line = pwg_db_fetch_row($req_table)) { $insertions .= 'INSERT INTO '.$ListTables[$j].' VALUES ('; for ($i=0; $i<$nb_fields; $i++) { $insertions .= '\'' . pwg_db_real_escape_string($line[$i]) . '\', '; } $insertions = substr($insertions, 0, -2); $insertions .= ");\n"; }
Et je ne vois pas comment contourner çà...
Dernière modification par Eric (2013-02-28 12:00:35)
Hors ligne
si c'est uniquement pour le nombre de colonne il y a http://ben.lobaugh.net/blog/7155/mysql- … in-a-table
et sinon tu peux demander à ton serviteur d'ajouter la méthode pwg_db_num_fields() :-) (ça cassera évidement la compatibilité 2.4)
Hors ligne
Merci mistic100 !
En fait, je crois que j'ai trouvé une autre méthode mais je dois encore la tester :
$req_table = pwg_query('DESCRIBE '.$ListTables[$j].';'); $nb_fields = pwg_db_num_rows($req_table); $req_table2 = pwg_query('SELECT * FROM '.$ListTables[$j]) or die(my_error()); while ($line = pwg_db_fetch_row($req_table2)) { $insertions .= 'INSERT INTO '.$ListTables[$j].' VALUES ('; for ($i=0; $i<$nb_fields; $i++) { $insertions .= '\'' . pwg_db_real_escape_string($line[$i]) . '\', '; } $insertions = substr($insertions, 0, -2); $insertions .= ");\n"; }
[edit]Comme cela, on conserve la compatibilité 2.4 ;-)[/edit]
Dernière modification par Eric (2013-02-28 13:47:02)
Hors ligne
Bonjour !
J'ai le même genre de souci... j'utilise mysql_num_rows, mysql_errno, et mysql_error dans Event Cats. (Rien du tout heureusement dans LCAS.)
Bon ben on va s'y remettre... génial je savais pas quoi faire durant les six prochains mois...
Hors ligne
mistic100 a écrit:
j'ai ajouté les méthodes pwg_db_errno() et pwg_db_error() (que pour 2.5 donc)
Et my_error() déjà livré dans Piwigo 2.4 ? Cà ne ferait pas doublon avec pwg_db_error() ?
Hors ligne
Ok, je ne savais pas. Merci pour l'info !
Donc, my_error devrait disparaitre au profit de pwg_db_error() et pwg_db_errno(), c'est çà ?
Hors ligne
Ah oui mais les fonctions dblayer n'apparaissent qu'à 2.1, en fait. Là on casse la compatibilité avec 2.0... c'est ennuyeux, il va falloir que je fasse évoluer ma galerie... si si, elle est en 2.0.10...
Bon, évidemment, il n'y en a pas beaucoup d'autres...
Hors ligne