[spip-dev] SPIP 3: URLs, retours de ligne...

Dev
1

Rapide retour de mes tests de migration avec l'actuelle beta SPIP 3 svn [19161]:

#1 - problème de réécriture URL avec des rubriques dont le titre est
un chiffre, par exemple "2012", et avec la configuration "URLs
Libres":

Au lieu de restituer la rubrique http://example.org/2012 SPIP renvoie
http://example.org/spip.php?page=article&id_article=2012 avec pour
résultat une erreur 404

Cela fonctionne en SPIP 3 avec "URLS Propres" : http://example.org/-2012-

La version désirée - http://example.org/2012 - fonctionne actuellement
sous SPIP 2.1.12 avec "URLs Propres" (version patchée urledit).

PS: je viens de tester sur grml.eu, le problème est reproductible :
http://obscurement.grml.eu/Concerts-2012
Essayez depuis cette page de visiter la rubrique "2012" dans le fil
d'ariane, vous aurez l'erreur 404.

#2 - conversion de caractères érronnée lorsque des tags de retour de
ligne HTML <br> ou <br/> sont utilisés dans le texte d'un article.

Dans SPIP 2.1.12 ces tags ne sont pas convertis, le résultat est donc
équivalent au _ préfixe habituel de SPIP.

Dans SPIP 3 r19161 ils ne sont plus présents dans le code généré (on
perd donc le retour de ligne), et sont remplacés par un caractère
ASCII corrompu (visualisé par un rectangle blanc dans le code source
de firefox).

PS: En testant sur grml.eu, je ne reproduis pas les caractères
corrompus. Ils sont simplement ignorés. Je constate toutefois que
grml.eu utilise la version [19122], alors que j'ai eu ce le problème
avec la [19161].

#3 - le plugin Compositions 3.0.2: nécessite Spip-Bonux v3 pour éviter
les messages d'erreur "Call to undefined function _t_ou_typo()" (mais
ne l'indique pas lors de l'activation).

Merci de m'indiquer s'il vaut la peine que je remonte ces broutilles
dans Trac, ou si tout cela a déjà été identifié/résolu.

Hormis cela, chapeau bas: SPIP 3 est beau, ergonomique, et je me
réjouis d'utiliser les fonctions étendues dans mes thèmes :slight_smile:

2

Salut,

3

Bien vu. Effectivement cela solutionne le problème.
Et tant pis pour les URL courtes.

4

PS: En testant sur grml.eu, je ne reproduis pas les caractères
corrompus. Ils sont simplement ignorés. Je constate toutefois que
grml.eu utilise la version [19122], alors que j’ai eu ce le problème
avec la [19161].

Et voilà, grml.eu est à jour avec un nouveau répertoire plugin_dist \o/

5

Merci!

Finalement, le rendu différent entre grml.eu et mon site de test perso
n'était pas lié à la version de SPIP, mais au navigateur: les
caractères corrompus sont masqués sous Chromium, mais visibles sous
Firefox.

Exemple : http://obscurement.grml.eu/Test-retours-de-ligne

J'ai entré manuellement un <br/> entre "Première ligne" et "Deuxième ligne".

- Résultat dans Chromium et autres Webkit: pas de retour de ligne,
caractère corrompu non visible (mais présent dans le code,
transmissible par copier-coller).
- Résultat dans Firefox: pas de retour de ligne, caractère corrompu en
lieu et place du tag <br/>.
- Ce caractère corrompu se retrouve également dans la meta-balise
"description" du header, endroit où le <br/> devrait être prohibé.

Voilà pour mes observations, en espérant que cela soit utile.

6

2012/3/27 Manuel Schmalstieg <webdev@ms-studio.net>

Merci!

Finalement, le rendu différent entre grml.eu et mon site de test perso
n’était pas lié à la version de SPIP, mais au navigateur: les
caractères corrompus sont masqués sous Chromium, mais visibles sous
Firefox.

Exemple : http://obscurement.grml.eu/Test-retours-de-ligne

J’ai entré manuellement un
entre « Première ligne » et « Deuxième ligne ».

ah faut continuer à observer alors … En effet je vois le caractère bizarre sur le tiens mais pas sur le miens :slight_smile:

Peux tu repasser sur le panneau plugin pour voir ?

http://bennyb.grml.eu/hop-1

ligne 1
ligne 2

7

Je viens de faire quelques essais supplémentaires, et au final il
s'agit d'un caractère de retour de ligne non-orthodoxe, combiné avec
le <br/>, qui déclenche le truc.

En dehors de ce cas-limite, je vois que le comportement par défaut
pour les retours de ligne simples (non-html) à changé: dans SPIP 2.1.x
ils étaient ignorés, dans SPIP 3 ils sont appliqués (traduits par un
<br class='autobr' />).

Cela me paraît judicieux, mais évidemment cela va engendrer des
problèmes de migration pour des sites truffés de retours de ligne
non-désirables... Comment peut-on provisoirement désactiver cette
gestion des retours de ligne? Et de manière générale, quel est le
moyen recommandé de personnaliser les règles de substitution de
TextWheel?

8

Je viens de faire quelques essais supplémentaires, et au final il
s'agit d'un caractère de retour de ligne non-orthodoxe, combiné avec
le <br/>, qui déclenche le truc.

peux-tu être plus précis ? quel est ce caractère non orthodoxe ?
est-ce que le bug persiste ?

En dehors de ce cas-limite, je vois que le comportement par défaut
pour les retours de ligne simples (non-html) à changé: dans SPIP 2.1.x
ils étaient ignorés, dans SPIP 3 ils sont appliqués (traduits par un
<br class='autobr' />).

Cela me paraît judicieux, mais évidemment cela va engendrer des
problèmes de migration pour des sites truffés de retours de ligne
non-désirables... Comment peut-on provisoirement désactiver cette
gestion des retours de ligne?

voir la discussion ici

et notamment
plugin / outil de "migration" pour les vieux sauts de ligne
éventuellement moisis

-- Fil

9

peux-tu être plus précis ? quel est ce caractère non orthodoxe ?
est-ce que le bug persiste ?

Après quelques tests à tête reposée, je constate que ce problème n'est
pas l'effet d'un "retour de ligne non-orthodoxe".

C'est simplement la présence d'un <br/> SUIVI d'un retour de ligne
automatique qui provoque la substitution par un iso-machin. Si un
caractère quelconque (autre qu'un espace) est inséré entre le <br> et
le retour de ligne, le problème ne survient pas.

Exemple: entrer les trois lignes suivantes dans le corps d'un article,
ou dans un commentaire, éventuellement sur l'un des sites-test cités
plus haut:

1) Test<br/>.
2) Test<br/>
3) Test<br/>Test

Résultat:
1): le retour de ligne est appliqué (avant et après le point).
2): le retour de ligne n'est PAS appliqué. Un isomachin est visible à
la place (sous Firefox)
3): le retour de ligne est appliqué.

A priori il doit exister une faille dans les expressions régulières
qui gèrent ces retours de ligne.

voir la discussion ici
Discuter chez rezo.net

et notamment
plugin / outil de "migration" pour les vieux sauts de ligne
éventuellement moisis
Connexion · GitLab

-- Fil

Merci pour les liens! Je vais étudier ça.

10

1) Test<br/>.
2) Test<br/>
3) Test<br/>Test

merci pour le test ; la correction est ici

-- Fil

11

Magnifique, ça fonctionne.

Pour le truc du désactivage optionnel en ajoutant la ligne
define('_AUTOBR', '');
dans mes_options.php, cela me donne aussitôt un message "Parse error:
syntax error, unexpected T_CONSTANT_ENCAPSED_STRING" ...

est-ce que l'archive.rezo.net aurait mangé un bout de code indispensable?