Project

General

Profile

Anomalie #3368

Validation XML - Liens (links/href, etc.)

Added by xdjuj - over 4 years ago. Updated about 3 years ago.

Status:
Fermé
Priority:
Normal
Assignee:
-
Target version:
Start date:
12/22/2014
Due date:
% Done:

0%

Resolution:
invalid
Navigateur:

Description

Dans le fichier squelettes-dist/inc-rss-item.html les liens (<link> <a>) sont de la forme :

href="[(#URL_RUBRIQUE|url_absolue)]" 

Or, les urls de la forme http://domaine.com/spip.php?page=article&id_article=24 posent un problème de validation, il faudrait que les liens soient de la forme http://domaine.com/spip.php?page=article&amp;id_article=24

Un simple

href="[(#URL_RUBRIQUE|url_absolue|texte_backend)]" 

règle le problème et ramène la validation XML.

Est-ce un bug ?

History

#1 Updated by Suske Suske over 4 years ago

Comme je disais sur IRC:
<Suske> si t'as testé et que ça passe
<Suske> + c'est valide alors que le code actuel ne l'est pas
<Suske> c'est une amélioration ;-)
<Suske> donc
<Suske> gogogo

En 2.1, 3.0 et 3.1 plizzzz: it's core/plugins/dist on the zone + core/branches...

#3 Updated by Suske Suske over 4 years ago

  • Status changed from Nouveau to Fermé
  • Resolution set to fixed

\o/ xdjuj

#4 Updated by b b over 4 years ago

Hop, il faudrait peut-être prendre en compte les remarques de cedric et fil avant de fermer ;)

http://article.gmane.org/gmane.comp.web.spip.zone.cvs/84306

#5 Updated by xdjuj - over 4 years ago

Ok.

C'est trop violent donc ?

Est-ce que htmlentities ou htmlspecialchars suffiraient sans créer d'effets de bords ?

#6 Updated by Suske Suske over 4 years ago

  • Status changed from Fermé to En cours
  • Target version set to 3.1
  • Resolution deleted (fixed)

#7 Updated by Fil _ over 4 years ago

si tu expliquais le problème rencontré, déjà… si c'est juste les & qui doivent être des &amp; il existe un filtre spécifique : quote_amp

#8 Updated by xdjuj - over 4 years ago

Je ne vois pas comment expliquer mieux que je ne l'ai fait dans l'objet du ticket.

J'ai un sitemap.xml généré automatiquement par SPIP. Il génère un XML non valide. En regardant "pourquoi" il n'est pas valide, il est remonté toutes les lignes contenant des URLs avec des paramètres supplémentaires :

http://domaine.com/spip.php?page=article&id_article=24

Si je "sécurise" cette URL :

http://domaine.com/spip.php?page=article&amp;id_article=24

Alors, le fichier est de nouveau valide.

C'est pour ça que j'ai ouvert un ticket, pour expliquer le problème et exposer mes observations.

  • |texte_backend règle le problème. Cerdic explique qu'il a des effets de bords, supprimons ce correctif raté,
  • |htmlentities ou specialchars encodent également les & donc règleraient aussi le problème,
  • tu dis qu'il existe quote_amp, qui également résoudrait le problème remonté ici.

La question est juste de dire qu'il y a un soucis, et de savoir comment "bien" le régler, car il existe manifestement plusieurs solutions, dont les débordements me dépassent.

#9 Updated by Fil _ over 4 years ago

Mais là je suppose que ton HTML n'est pas valide non plus, si #URL_RUBRIQUE (#URL_ARTICLE) produit un & au lieu d'un &amp;.

=> de mémoire, #URL_ARTICLE est censé produire un &amp; ; c'est donc ça à mon avis qu'il faudrait vérifier/débuguer/corriger, et non la conséquence dans un squelette donné
=> par ailleurs, si je me suis trompé ci-dessus, sache qu'ajouter |quote_amp est garanti sans effet de bord

#10 Updated by xdjuj - over 4 years ago

Salut :)

Je parle bien des "#URL"(_ARTICLE / _RUBRIQUE). Je suis aussi étonné que toi, car je me demande bien pourquoi je suis le premier à le constater et non pas des liens dans mon HTML.

Et je parle aussi des squelettes "de base" (c'est à dire non touchés).

D'après mes lectures (rapides) sur Google, |htmlentities/specialchars semblent utilisés "par ailleurs", je supposais donc que c'était aussi une solution cool.

Par contre, je vais essayer de jeter un oeil demain précisément sur "pourquoi" les URL sont rendues comme ça par le SPIP, il y a peut être une surcharge ailleurs qui produit ces urls non protégées, parce que comme toi je pensais que tout ça était bien protégé.

Merci et bonne fin de dimanche :)

#11 Updated by xdjuj - over 4 years ago

Salut fil

C'est bon j'ai compris.

Le bug se produit sur SPIP 2.1.12 [18566] (pas testé ailleurs pour l'instant) sur les "articles virtuels" (articles de redirection).

Du coup, il me faut tout de même rajouter |quote_amp sur link et guid isPermaLink sinon, si le lien de redirection de l'article contient un & qui n'est pas protégé.

  • si je vais côté base de donnée, et que je force le lien http://domaine.com/?page=article&amp;id_article=25 (en le saisissant donc dans le champ CHAPO, puisque c'est là qu'il se trouve en SPIP 2) => avec le filtre |quote_amp la valeur retournée est bonne.

Moralité, #URL_ARTICLE renvoi une valeur "non protégée" lorsqu'il s'agit d'un article de redirection.
Côté Flux RSS rajouter |quote_amp permet de résoudre le problème (qui est peut être du coup un peu plus profond qu'un simple flux RSS).

Est-ce que je modifie mon commit pour appliquer |quote_amp à la place ou est-ce que vous pensez que c'est #URL_ARTICLE qui bug et donc vous allez le corriger ?

#12 Updated by xdjuj - over 4 years ago

Actuellement absent, je ne prendrai connaissance de votre message qu'à mon retour le lundi 5 janvier.

#13 Updated by Fil _ over 4 years ago

ah donc c'est bien un bug du core (bravo !)

il faudra modifier le ticket en conséquence (ou plutôt, en créer un autre), et supprimer les filtres que tu as rajoutés

#14 Updated by Eric Lupinacci over 4 years ago

Pour mémoire : le commit https://core.spip.net/projects/squelettes-dist/repository/revisions/86810 n'a toujours pas été supprimé.

#15 Updated by b b about 3 years ago

Hum, xdjuj ça fait un bout de temps que tu as envoyé le commit et tu ne l'as toujours pas annulé ? Faut-il qu'on le fasse à ta place ?

#16 Updated by b b about 3 years ago

Je viens de vérifier en 3.2 et en 3.1 et c'est bien l'url de l'article (et non celle de la redirection) qui est affichée dans le flux RSS et dans le sitemap, le bug signalé ici n'est donc pas présent.

Le bug se produit sur SPIP 2.1.12 [18566] (pas testé ailleurs pour l'instant) sur les "articles virtuels" (articles de redirection).

Je ne comprends vraiment pas pourquoi le correctif a été envoyé dans les branches 3.0 et 3.1 alors que l'auteur signale qu'il observe le bug sur la branche 2.1. Bref, je vais annuler cette modification, fermer le ticket et je laisse l'auteur en créer un nouveau sur la bonne branche.

#17 Updated by b b about 3 years ago

  • Status changed from En cours to Fermé
  • Resolution set to invalid

Also available in: Atom PDF