Hello,
Je viens de m'apercevoir d'un petit bug si l"on veut editer un tag creer au départ avec un apostrophe.
exple avec un tag : aujourd'hui qui s'affiche correctement apres ca creation
si je l'edit par exple pour mettre Aujourd'hui ca me renvoie Aujourd\'hui.
une idée ?
Hors ligne
C'est un comportement normal. En effet, en php, les apostrophes sont interprétés comme des marquants de chaines. Par exemple dans les fichiers de langue on a :
$lang['hint_customize'] = 'personnaliser l\'apparence de la galerie';
Pour éviter que les apostrophes soient interprétés par php, on ajoute un "\" devant. Les Tags ainsi que tous les champs texte de PWG disposent d'un mécanisme qui détecte les apostrophes et ajoute automatiquement "\" devant.
Donc, dans ton cas, pas d'inquiétude. Tu peux laisser le "\" ou le retirer. Il sera automatiquement ajouté à la validation du tag.
Hors ligne
Ah ! J'avais pas pigé dans ce sens !
Alors visiblement, il doit effectivement y avoir un bug sur le mécanisme dont je parlais. Il ne détecterai pas la présence de "\".
Et si tu edites le tag en question, tu supprimes le "\" et tu valides, çà fait quoi ?
Sinon, autre solution : Agir directement dans la BDD pour voir si çà corrige le pb. Le script se mélange peut-être les pinceaux...
[Edit]Ou alors un effet de bord avec le plugin TagOnIndex. J'ai fais le test chez moi (sans le plugin) et y a pas de soucis.[/Edit]
Dernière modification par Eric (2007-08-18 19:42:08)
Hors ligne
lol
En fait, le problème vient du fait que lors de l'édition d'un tag, les guillemets sont mal gérés...
Si on édite un tag, n'importe lequel et qu'on décide d'y mettre un guillemet simple, paf, ca met un \ devant
Dernière modification par P@t (2007-08-18 19:43:46)
Hors ligne
P@t a écrit:
lol
En fait, le problème vient du fait que lors de l'édition d'un tag, les guillemets sont mal gérés...
Si on édite un tag, n'importe lequel et qu'on décide d'y mettre un guillemet simple, paf, ca met un \ devant
oui c'est ca que j'ai identifé et peut etre mal expliqué...
EDIT : pas de probleme avec tagsOnIndex
EDIT2: J'ai rectifié direct en BDD. c'est ok. mais je vais faire remonter le bug.
Dernière modification par sakkhho (2007-08-18 19:51:23)
Hors ligne
Bon ben je vais retourner me coucher, moi...
Effectivement, c'est un bug de gestion des guillemets simples. Marrant que personne ne s'en soit rendu compte avant.
Le Team ne devrait pas mettre longtemps à corriger çà pour la prochaine version.
Hors ligne
Je regarderai ca à mon retour...
Si personne ne l'a fait avant ;-)
En attendant, sakkhho, tu peux faire un rapport dans le gestionaire de bugs?
Dernière modification par P@t (2007-08-18 19:50:21)
Hors ligne
Hors ligne
boudiou j'ai honte, j'ai découvert ce bug il y a 3-4 mois et je me rends compte que je l'ai pas signalé...
désolé
Hors ligne
generalement faut faire un str replace pour gerer ca, moi j ai fais ca dans la partie admin de l'edito pour autoriser les '
str_replace("\'", "'", $_POST['nbc_editoonindex_titlebar']),
donc un coup de cette fonction avant de stocker dans la DB
a+
Dernière modification par Nicco (2007-08-19 03:17:35)
Hors ligne
Nicco a écrit:
generalement faut faire un str replace pour gerer ca, moi j ai fais ca dans la partie admin de l'edito pour autoriser les '
str_replace("\'", "'", $_POST['nbc_editoonindex_titlebar'])
Oula, t'es sur que ca fonctionne ca???
J'aime pas du tout le "'"
Il existe une fonction spéciale pour ca: stripslashes
Dans ton cas, ca donnera:
stripslashes ( $_POST['nbc_editoonindex_titlebar'] )
tout simplement
Dernière modification par P@t (2007-08-19 12:02:29)
Hors ligne
Le problème viens de la fonction mysql_escape_string qui modifie la chaine avant de l'envoyer vers la base de données (dans le fichier admin/tags.php)
if (function_exists('mysql_real_escape_string')) { $tag_name = mysql_real_escape_string($_POST['tag_name-'.$tag_id]); } else { $tag_name = mysql_escape_string($_POST['tag_name-'.$tag_id]); }
Ce bout de code est utilisé pour la modification d'un tag, mais ne l'est pas pour l'ajout d'un tag...
Je pense qu'il faut le supprimer, tout simplement, vu que l'ajout de tag de pose aucun problèmes...
Dernière modification par P@t (2007-08-19 13:14:21)
Hors ligne
A mon avis, mieux vaut le laisser et le rajouter là où il manque, parce que sinon ca risque d'ouvrir les portes pour des injections sql... Toute requête qui contient un champ venant de l'utilisateur doit être "échapée" avec des slash...
Hors ligne