Mises à jour de yAronet - Page 12

Hello,

Apparemment le module de sondages ne fonctionne plus (une fois que l'on clique sur le bouton valider, le fenêtre devient blanche et aucune balise n'apparaît dans le champ message)

Au lieu d'attribuer les points squalyl/squalyl/tripen... pourquoi ne pas faire un bouton et éviter le spam ?

malheureux! tu veux nous faire perdre notre raison de vivre???

en filigrane, je crois qu'il demande un point montreuillois



([u]/[/u])

Pour quelle occasion sacripant ?

Je sais pas, un truc en rapport avec les abus de pouvoir sans doute

./331 : corrigé

J'ai remis les target="_blank" dans les [url] puisque vous êtes plusieurs à m'avoir très subtilement (</SARCASM> comme dirait l'autre) laissé entendre que c'était pas top. Le bug des tags [img] avec taille qui décodait mal devrait aussi être corrigé (mais les posts qui avaient le bug ne seront pas automatiquement mis à jour).

Zeph (./337) :
./331 : corrigé

J'ai remis les target="_blank" dans les [url] puisque vous êtes plusieurs à m'avoir très subtilement (</SARCASM> comme dirait l'autre) laissé entendre que c'était pas top. Le bug des tags [img] avec taille qui décodait mal devrait aussi être corrigé (mais les posts qui avaient le bug ne seront pas automatiquement mis à jour).

Merci !

(pour ma part, je vois encore des target="self", je ne sais pas si c'est normal)

un grand merci pour les liens.

vince (./340) :
(pour ma part, je vois encore des target="self", je ne sais pas si c'est normal)

Heu non en effet j'avais inversé le test, les urli faisaient des _blank et les url des _self, c'est corrigé.

En fait c'est une vengeance

Ah tiens j'y pense.
Travail pour Zeph : déterminer pourquoi on se tape un BONNE ANNÉE le premier janvier... Et aussi le premier février.

parce queuh

(rien, dsl ><)

Normalement c'est corrigé mais pas rétroactif sur les anciens posts, je ferai une reprise globale à la prochaine "grosse" maj du parseur (sauf que j'ai besoin de php 5.3, donc de yAro, donc ça attendra un peu ^^)

J'oubliais :

Yoshi Noir (./345) :
Travail pour Zeph : déterminer pourquoi on se tape un BONNE ANNÉE le premier janvier... Et aussi le premier février.

Déjà corrigé, mauvaise langue, tu aurais pu au moins attendre le 1er février de la prochaine année avant de râler

Folco (./348) :
(rien, dsl ><)

Et ça c'est corrigé par le nouveau parseur aussi ? Ya pas de ';' dans mon post

arg, c'est parce que le "<" est transformé en "&lt;" avant parsing, ça va être chiant à éviter ça :/

Je ne sais pas comment sont faites les mises en forme des posts de yAronet, mais quand j'ai eu à faire ce genre de chose, je n'appliquais pas le résultat directement au texte. La première chose que j'ai faite a été de définir un nouveau type de balise pour contenir les informations de mise en forme. Par exemple {numéro} et je neutralise les balises déjà présentes avec {{} ou {0}. Ensuite, je cherche les éléments à transformer, par exemple :) devient {5} avec <img.../> à l'indice 5 d'un tableau. On peut définir les mises en forme à l'avance et juste placer des balises avec les bons numéros ou les définir au fur et à mesure, mais on peut se retrouver avec plusieurs fois la même chose. On peut aussi mélanger les deux : le tableau contient déjà tout ce qu'il faut pour les smileys, mais va grandir pour les balises vers les images extérieures. Bien sûr, il faut rechercher les éléments dans le bon ordre : image puis smileys pour éviter de se retrouver avec des smileys dans les adresses... et la balise est choisie de façon à ne jamais faire partie d'un élément reconnu. Par exemple, {} n'est pas utilisable si le smiley :{ existe. Le texte résultant est transformé pour pouvoir être affiché (donc on neutralise les balises HTML) et finalement, on remplace les balises par leur contenu et les balises neutralisées au début sont déneutralisées.

Voilà un post sans doute inutile, mais bon

Très grosso modo c'est comme ça que ça fonctionne, avec quelques problèmes qui viennent s'ajouter comme les balises à arguments, les balises qui ne peuvent pas s'imbriquer l'une dans l'autre, les balises qui déclenchent un contexte de parsing particulier (comme pre ou table par exemple), etc. Mais le souci c'est qu'il faut qu'un "<" présent dans un post soit échappé en "&lt;" à un moment où à un autre, pas question de le laisser tel quel à l'affichage. Soit on échappe avant de transformer les balises et ça provoque le bug de Folco, soit on échappe après et ça détruit toutes les balises qui ont été appliquées, soit il faut faire qqchose de plus fin qui ne s'applique qu'aux zones de texte non transformées. C'est tout à fait faisable, mais pas tout de suite

Zeph (./354) :
quelques problèmes qui viennent s'ajouter comme les balises à arguments, les balises qui ne peuvent pas s'imbriquer l'une dans l'autre, les balises qui déclenchent un contexte de parsing particulier (comme pre ou table par exemple), etc.

C'est justement pour ça que j'avais utilisé la méthode que j'ai présentée. La balise peut également représenter un bloc de texte dans un autre format qui est transformé d'une autre façon que le texte normal. Le remplacement par la balise permet de ne plus considérer le texte lors des transformations suivantes (le texte dans l'autre format se trouve dans le tableau dont j'ai parlé).

soit il faut faire qqchose de plus fin qui ne s'applique qu'aux zones de texte non transformées.

Avec cette méthode, on n'a plus du tout d'éléments transformés dans le texte à échapper. Ils sont tous remplacés par des balises {numéro} qui ne craignent pas l'échappement.

C'est tout à fait faisable, mais pas tout de suite

On est d'accord ^^

D'accord, tu veux donc considérer le texte brut comme devant être traité par une balise dont l'effet est d'appliquer un échappement au moment de l'affichage ? Ça revient à peu près au même, je sais pas ce qui est le plus rapide à coder entre les deux méthodes, j'ai l'impression qu'il y a un cas particulier auquel je n'ai pas pensé et qui rend au moins l'une des deux peu commode à implémenter, mais il faut que je prenne le temps d'y réfléchir

Test de caractère unicode : 漢字
habituellement, quand on fait citation-sauver puis insérer les citations sauvées, ça déconne. Mais jusqu’à présent il me semble que ça ne posait pas problème quand on cliquait simplement sur citer. Je vais tester

Edit : voilà, bug qui apparaît dans la popup citer (mais pas dans la popup éditer) : le & est échappé en &28450;&amp;#23383;amp;, il apparaît &amp;# ce qui évidemment n’affiche pas les caractères en question une fois posté. Si je fais éditer, la fenêtre semble identique par ailleurs mais ce problème n’apparaît pas, le & n’est pas transformé. Je ne crois pas que ce bug existait avant (je peux me tromper)

J'ai l'impression qu'à force d'accumuler les hacks pour reproduire exactement le comportement actuel, je vais passer mon temps à casser des trucs en essayant d'en corriger d'autres.

La seule vraie solution serait de : 1° corriger l'échappement des entités HTML (cf. discussion avec RHJPP) et 2° passer yN en Unicode (UTF-8 ou autre) ; c'est un gros boulot, donc ça risque de prendre un moment.

Bon courage, et merci de t'y coller (quel que soit le résultat) !


(edit: dans le sens que je te remercie, et pas que je tente de t'ordonner quoi que ce soit)

Ouais, bon courage (x_x)