[spip-dev] beta 15

Dev
1

Voilà la beta 15. La mise à jour de la base corrige les slashes
comme annoncé. J'ai d'autre part fait la chasse aux stripslashes
dans le code. J'ai testé un peu chez moi, mais il faudrait confirmer
en grandeur nature (uzine ?).

a+

Antoine.

2

@ Antoine Pitrou (pitrou@free.fr) :

Voilà la beta 15. La mise à jour de la base corrige les slashes
comme annoncé. J'ai d'autre part fait la chasse aux stripslashes
dans le code. J'ai testé un peu chez moi, mais il faudrait confirmer
en grandeur nature (uzine ?).

Pas tout à fait : regarde bien le titre de la fenetre articles.php3 quand tu
envoies un article avec un titre contenant un ".

A part ça, pour ce que j'en vois, la base contient exactement ce qu'on lui
envoie !

-- Fil

3

Fil wrote:

Pas tout à fait : regarde bien le titre de la fenetre articles.php3 quand tu
envoies un article avec un titre contenant un ".

OK, c'est corrigé.

4

Excellent !
Je peux donc installer dans la beta15/ le nouveau inc_texte.php3, dans
lequel pas mal de choses ont été nettoyées, et qui comprend le raccourci

<code> ... </code>

Tout le texte entre ces deux balises est affiché en mode texte préformaté,
les tabulations remplacées par 8 espaces, les < échappées en &lt;, les & en
&amp;... ce qui permet de faire des listings corrects sans se fatiguer.

J'ai testé en passant comme texte le fichier inc_texte.php3 lui-même, et il
s'affiche parfaitement ! (Le dernier souci concernait les expressions du
type
    echo "\n";
car le \ disparaissait dans la version beta14/ ; grâce aux dernières modifs
d'Antoine ce n'est plus le cas.

-- Fil

5

Cool, heu par contre :

- pourquoi ereg_replace("\t"," ",$lecode);

- pour &lt; et &amp;, il y a htmlspecialchars().

- class='spip_code' au lieu de 'spipcode' pour harmoniser ?

- je ne crois pas que le <pre> soit une bonne idée, parce
que ça fout la mise en page en l'air si les lignes sont trop
longues (et ça dépend du réglage du brouteur, donc un type
avec des grosses fontes va se retrouver avec un truc infâme).
Il vaut mieux laisser le webmestre régler ça dans le css.
Par contre, il faut alors transformer les \n en <p>.

Fil wrote:

6

ah oui, et en plus pour le \n -> <br>, il y a nl2br().... :))

7

@ Antoine Pitrou (pitrou@free.fr) :

- pourquoi ereg_replace("\t"," ",$lecode);

Si tu colles un texte plein de tabulations, autant que ça soit joli.

Pour le reste, c'est corrigé (y compris le fichier aide)

bonne nuit
-- Fil

8

Reste un petit bug que je ne comprends pas :

Si j'entre <code><? echo "toto" ?></code>
j'obtiens bien, dans l'espace privé : &lt;? echo....
mais "voir en ligne" me donne &amp;lt;? echo...

Il y a donc un filtre qui en fait trop. Où est-il ? Pas trouvé (dodo)

-- Fil

9

Certainement interdire_scripts()

Bonne nuit,

Fil wrote:

10

@ Antoine Pitrou (pitrou@free.fr) :

Certainement interdire_scripts()

Voilà, c'est corrigé (inc-calcul-squel.php3) ; j'ai aussi corrigé un petit
truc dans ecrire/inc_texte.php3 (supprimé l'usage de global pour les
échappements)

-- Fil

11

Fil wrote:

Voilà, c'est corrigé (inc-calcul-squel.php3) ;

Heu, tu es sûr que ça corrige ? Ca m'étonnerait :wink:

12

Bonjour,

les tabulations remplacées par 8 espaces

Pourquoi donc ??? Les tabulations permettent d'aligner des choses et
ne sont pas forcément de même taille ...

test1[tab]test2
t3[ tab ]t4

-Nicolas

13

Bonjour,

je ne crois pas que le <pre> soit une bonne idée, parce que ça fout
la mise en page en l'air si les lignes sont trop longues

Si on veut afficher un listing, c'est justement pour respecter
exactement l'intégrité les lignes.

-Nicolas

14

@ Antoine Pitrou (pitrou@free.fr) :

> Voilà, c'est corrigé (inc-calcul-squel.php3) ;
Heu, tu es sûr que ça corrige ? Ca m'étonnerait :wink:

Oui ça marche ! (Attention, il faut purger le cache pour faire apparaître
le bon résultat). J'ai changé l'ordre des filtres, et passé
interdire_scripts() en dernier ; du coup propre() travaille sur un script
contenant <? et le transforme bien en &lt;?, que le filtre
interdire_scripts() ne touche pas...

@ Nicolas Hoizey (nhoizey@phpheaven.net) :

> les tabulations remplacées par 8 espaces
Pourquoi donc ??? Les tabulations permettent d'aligner des choses et
ne sont pas forcément de même taille ...
test1[tab]test2
t3[ tab ]t4

Si je laisse les tabs telles quelles, le brouteur les affiche comme une
seule espace ; et, dans le cas où les tabs servent à l'indentation, ma
méthode fonctionne très bien. Ailleurs, évidemment, c'est moins bien, mais
de toutes façons on ne contrôle plus vraiment la largeur des caractères
donc...

-- Fil

15

Si je laisse les tabs telles quelles, le brouteur les affiche comme
une seule espace

Pas avec un '<pre>', si ???

et, dans le cas où les tabs servent à l'indentation, ma méthode
fonctionne très bien.

Mais elle ne fonctionne pas pour des fichiers de config comme par
exemple '/etc/hosts' ...

Ailleurs, évidemment, c'est moins bien, mais de toutes façons on ne
contrôle plus vraiment la largeur des caractères donc...

Bin si, on prend une police non proportionnelle comme 'courrier' et
c'est nickel.

-Nicolas

16

@ Nicolas Hoizey (nhoizey@phpheaven.net) :

> Si je laisse les tabs telles quelles, le brouteur les affiche comme
> une seule espace

Pas avec un '<pre>', si ???

Dans l'espace privé de spip, et sur mon brouteur habituel, si. Fais l'essai:
commente la ligne en question dans inc_texte...

-- Fil

17

Si je laisse les tabs telles quelles, le brouteur les affiche
comme une seule espace

Pas avec un '<pre>', si ???

Dans l'espace privé de spip, et sur mon brouteur habituel, si.

Et pas dans l'espace public ???

C'est donc qu'il y a autre chose qui modifie le comportement du
'<pre>' puisqu'il est prévu par la norme que '<pre>' conserve
totalement l'"apparence" du texte, comme avec l'exemple suivant :

<html>
<pre>
toto tata titi
toto_2 tata_2 titi_2
</pre>
</html>

(ce sont des tabulations, mais j'ai l'impression que mon MUA les
transforme en espaces ... :frowning: )

-Nicolas

18

@ Nicolas Hoizey (nhoizey@phpheaven.net) :

> Dans l'espace privé de spip, et sur mon brouteur habituel, si.
Et pas dans l'espace public ???

si ; mais c'est qu'on n'utilise pas <pre> : on a recours à <tt> et <br> (et
je suis d'accord avec Antoine). Ta solution : fais un filtre supplémentaire
qui reprend les parties
   <tt><div align='left' class='spip_code'>.....</div></tt>
du texte et les retransforme en ce que tu veux.

-- Fil

19

Nicolas Hoizey wrote:

Bonjour,

> je ne crois pas que le <pre> soit une bonne idée, parce que ça fout
> la mise en page en l'air si les lignes sont trop longues

Si on veut afficher un listing, c'est justement pour respecter
exactement l'intégrité les lignes.

Et, heu, c'est possible de régler ça dans les CSS ?

20

Salut,

Trois petites modifs dans les fichiers:

/ecrire/inc.php3
/ecrire/recherche.php3
/ecrire/index.php3

Il s'agit du positionnement du pav=E9 de recherche dans la page: il
passe en bas =E0 gauche sur toutes les pages. C'est une fonction qui
concerne toutes les pages (navigation dans le site), en m=EAme temps
faut =E9viter de charger la colonne de gauche; en le pla=E7ant en bas de
tableau, =E7a me semble un bon compris. De plus, son =E9nonc=E9 devient
plus explicite ("Recherche titre", dans le genre, fallait oser ;-).

Au passage, j'en profite pour que les liens de messagerie interne (le
c'htit "M" vert) ne s'affichent que pour les r=E9dacteurs qui se sont
connect=E9s depuis 15 jours. Mine de rien, on all=E8ge pas mal
l'interface g=E9n=E9rale comme =E7a.

ARNO*