ça a l'air encore d'un bug PCRE: ligne 1407 de inc/texte.php, remplacer:
if (preg_match(",^ *<([^>]*)>,", $note_texte, $regs)){
par
if (preg_match(",^<([^>]*)>,", $note_texte, $regs)){
et ça marche, mais quel rapport ?
J'envoie qcch de plus général dans un moment, j'avais qqch sur le feu dans ce fichier.
Solution d'urgence: mets un return plutot qu'un espace ici:
merci pour 10301 qui résoud
"tout" ? C'est visiblement une vieille Regexp (j'y ai pas touchés)
dont le blindage insuffisant se révèle soudainement.
ho ho jolie réponse :-p
si tu détruis la vieille grange en reculant avec ta voiture, tu peux
dire que c'est de la faute de la grange qui n'était pas blindée -- ça
n'est pas faux !
Pour moi ça prouve surtout qu'il faut augmenter nos tests unitaires,
surtout quand on s'attaque aux parties dites "vieilles" du code. (et
tous les membres de la zone peuvent en faire) Pourquoi ne commites-tu
pas le test que tu as mis en commentaire de [10301] ?
Oui, mais les ltrim rajoutés en [10303] réintroduisent (du moins dans ma version de PHP) le bug que [10301] avait corrigé en réduisant la fonctionnalité.
Ce n'est en fait pas un bug PCRE derrière, car même en utilisant des strpos le problème persiste.
A priori c'est plutot après qu'on se met à réinterpréter à tort qqch.
Ce n'est en fait pas un bug PCRE derrière, car même en utilisant des
strpos le problème persiste.
A priori c'est plutot après qu'on se met à réinterpréter à tort qqch.
OK vu, c'est l'ordre des choses qui a changé : si je schématise,
avant on avait à interpréter
[[ [truc->...] ]]
et maintenant on a
[[ <a ...>truc</a> ]]
et du coup le test sur le nom de la note (<....>) attrape le <a ...>
Un fix rapide c'est d'interdire les guillemets " et ' dans les noms de
notes, mais c'est plus un contournement qu'autre chose.
Ce n'est en fait pas un bug PCRE derrière, car même en utilisant des
strpos le problème persiste.
A priori c'est plutot après qu'on se met à réinterpréter à tort qqch.
OK vu, c'est l'ordre des choses qui a changé : si je schématise,
avant on avait à interpréter
[[ [truc->...] ]]
et maintenant on a
[[ <a ...>truc</a> ]]
et du coup le test sur le nom de la note (<....>) attrape le <a ...>
oui, j'en étais là aussi.
Un fix rapide c'est d'interdire les guillemets " et ' dans les noms de
notes, mais c'est plus un contournement qu'autre chose.
Oui. Cela dit ça montre autre chose: si j'ai l'idée d'écrire:
[[<b>Remarque</b>....]]
aujourd'hui comme hier SPIP va considérer que "b" est le nom de la note, et le "</b>" restant va complètement casser la structure xml.
J'aurais donc plutot envie de controler qu'il n'y a pas "</NOM_DE_NOTE>" plus loin.
Au passage, je trouve ce système de note pas très pratique: si je veux une numérotation automatique autre qu'en chiffres arabes (a b c, i ii iii iv v, * ** *** etc) il n'a pas moyen de greffer une fonction qui le fasse, c'est dommage.
