[SPIP Zone] URLs arbo et segments numériques

Archives Zone
1

Bonjour

J'ai un petit soucis sur les URLs arbos et les articles qui ont un segment numérique
à savoir
http://site/x/y fonctionne bien

mais
http://site/2016/y me renvoie vers un autre article

pourtant j'ai bien désactivé, cette ligne du htacess (à priori rien à voir)
#RewriteRule ^([1-9][0-9]*)$ spip.php?action=redirect&type=article&status=301&id=$1 [QSA,L]

J'ai l'impression que cela vient de arbo.php
Est ce que cela parle à quelqu'un ?

--
_________________________________________
http://www.erational.org

2

Hello,

Par défaut, SPIP considère qu'un nombre est automatiquement un numéro
d'article.

http://spip.truc/1023 renvoie à l'article 1023.

Démonstration :

Je n'ai jamais trouvé la parade, peu importe le type d'url activé
(exemple ici avec des url propre : http://p.henix.be/391).
Je pense que c'est lié au core en lui-même, j'avais ouvert un ticket il
me semble, il y a longtemps, mais je ne le retrouve plus (faut dire que
redmine, pour la recherche de vieux truc, c'est pas top...).

Le 24/07/17 à 18:53, erational a écrit :

Bonjour

J'ai un petit soucis sur les URLs arbos et les articles qui ont un
segment numérique
à savoir
http://site/x/y fonctionne bien

mais
http://site/2016/y me renvoie vers un autre article

pourtant j'ai bien désactivé, cette ligne du htacess (à priori rien à
voir)
#RewriteRule ^([1-9][0-9]*)$
spip.php?action=redirect&type=article&status=301&id=$1 [QSA,L]

J'ai l'impression que cela vient de arbo.php
Est ce que cela parle à quelqu'un ?

3

Le 24/07/2017 à 19:11, Debondt Didier a écrit :

Hello,

Par défaut, SPIP considère qu'un nombre est automatiquement un numéro
d'article.

http://spip.truc/1023 renvoie à l'article 1023.

Oui, cela vient avec le .htaccess

Mais si tu commentes la ligne, cette fonctionnalité disparait
#RewriteRule ^([1-9][0-9]*)$ spip.php?action=redirect&type=article&status=301&id=$1 [QSA,L]

http://spip.truc/1023 renvoie à la page d'accueil (ou 404) selon le serveur
Je ne vois pas de problème donc à ce niveau

mon problème est différent
on a une configuration URLs arbo sans préfixe

// urls arborescentes sans prefixes
  $GLOBALS['url_arbo_types'] = array(
      'article'=>'',
     'rubrique'=>'',
     'breve' => '',
     'site' => '',
     'mot'=>'',
     'auteur' => ''
);

$GLOBALS['url_arbo_parents'] = array(
     'article' => array(),
     'rubrique' => array(),
     'breve'=> array(),
     'site' => array(),
     'mot' => array(),
     'auteur' => array()
);

j'ai un article 100 avec une URL http://site/2016/y
il renvoie bien à l'article 100

ensuite si je crée une nouvel article 101
avec l'URL http://site/2016/z , il me renvoie à l'article 100 au lieu de 101

idem pour toutes les articles qui auront le segment 2016

j'ai loupé qqchose ?

Démonstration :

{where} - SPIP

Je n'ai jamais trouvé la parade, peu importe le type d'url activé
(exemple ici avec des url propre : http://p.henix.be/391).
Je pense que c'est lié au core en lui-même, j'avais ouvert un ticket il
me semble, il y a longtemps, mais je ne le retrouve plus (faut dire que
redmine, pour la recherche de vieux truc, c'est pas top...).

Le 24/07/17 à 18:53, erational a écrit :

Bonjour

J'ai un petit soucis sur les URLs arbos et les articles qui ont un
segment numérique
à savoir
http://site/x/y fonctionne bien

mais
http://site/2016/y me renvoie vers un autre article

pourtant j'ai bien désactivé, cette ligne du htacess (à priori rien à
voir)
#RewriteRule ^([1-9][0-9]*)$
spip.php?action=redirect&type=article&status=301&id=$1 [QSA,L]

J'ai l'impression que cela vient de arbo.php
Est ce que cela parle à quelqu'un ?

--
_________________________________________

4

Je ne vois pas très bien ce que tu attends, car tu configures les URLs arbos avec aucune relation de parent ni préfixe, donc du coup comment le module de decodage est-il censé interpréter les segments ?

Je pense que là il matche sur le segment 2016/ qui doit avoir une correspondance en base et le x ou y sont ignorés
Mais c'est même un coup de bol, j'aurai plutôt parié pour une 404 qui est normalement la règle si un des segments est inconnu.
Peut-être qu'il matche quand même x et y, ce qui t'évite la 404, mais comme le premier segment 2016 a déjà matché il reprend pas en compte le nouvel id_article qu'il trouve.

Difficile de te dire ce qu'il se passe de manière exacte sans avoir la base en main et faire du debug, car ce decodage d'URLs arbos est assez complexe.
Ce que je peux dire c'est que je pense que tu l'utilises de manière borderline car tu as des segments dans tes URLs mais qui ne correspondent pas à de la hierarchie d'objets, donc ce n'est pas totalement surprenant que tu puisses tomber dans des cas pas prévus.

Peut-être ça peut se réparer/compléter pour corriger ce cas, mais à voir.

--
Cédric

erational a écrit :

// urls arborescentes sans prefixes
  $GLOBALS['url_arbo_types'] = array(
      'article'=>'',
     'rubrique'=>'',
     'breve' => '',
     'site' => '',
     'mot'=>'',
     'auteur' => ''
);

$GLOBALS['url_arbo_parents'] = array(
     'article' => array(),
     'rubrique' => array(),
     'breve'=> array(),
     'site' => array(),
     'mot' => array(),
     'auteur' => array()
);

j'ai un article 100 avec une URL http://site/2016/y
il renvoie bien à l'article 100

ensuite si je crée une nouvel article 101
avec l'URL http://site/2016/z , il me renvoie à l'article 100 au lieu de
101

idem pour toutes les articles qui auront le segment 2016

j'ai loupé qqchose ?

5

Le 25/07/2017 à 10:12, Cédric Morin a écrit :

Je ne vois pas très bien ce que tu attends, car tu configures les URLs arbos avec aucune relation de parent ni préfixe, donc du coup comment le module de decodage est-il censé interpréter les segments ?

sans les préfixes, il faudrait le module ignore les segments pour prendre l'intégralité de l'expression '2016/x' (ce que j'ai dans la base)

Je pense que là il matche sur le segment 2016/ qui doit avoir une correspondance en base et le x ou y sont ignorés
Mais c'est même un coup de bol, j'aurai plutôt parié pour une 404 qui est normalement la règle si un des segments est inconnu.
Peut-être qu'il matche quand même x et y, ce qui t'évite la 404, mais comme le premier segment 2016 a déjà matché il reprend pas en compte le nouvel id_article qu'il trouve.

cela marche bien lorsque le 1er segment n'a pas numérique

archive-2016/x
archive-2016/y

cela ne lève pas d'ambiguité

Difficile de te dire ce qu'il se passe de manière exacte sans avoir la base en main et faire du debug, car ce decodage d'URLs arbos est assez complexe.
Ce que je peux dire c'est que je pense que tu l'utilises de manière borderline car tu as des segments dans tes URLs mais qui ne correspondent pas à de la hierarchie d'objets, donc ce n'est pas totalement surprenant que tu puisses tomber dans des cas pas prévus.

Peut-être ça peut se réparer/compléter pour corriger ce cas, mais à voir.

on pourrait peut-être chercher en 1er l'expression complète 'x/y' et ensuite les segments ?

l'alternative serait de créer un nouveau format "arbo libre"
mais on se rencontre alors un autre soucis, le module d'édition avec editer_url segmente toujours avec le séparateur (/) (il me semble)

merci en tout cas pour ta réponse
je vous tiens au courant si cela trouve une solution

--
_________________________________________

6

erational a écrit :

cela marche bien lorsque le 1er segment n'a pas numérique

archive-2016/x
archive-2016/y

cela ne lève pas d'ambiguité

Alors ça vient peut-être du sql_in de la ligne

qui fait un quote numérique, car je vois que juste la ligne au dessus j'ai fait un quote explicite en 'text'
Il faut peut-être remplacer ce sql_in par un

'(url=' . sql_quote("$type/$url_segment", '', 'TEXT')
. ' OR url=' . sql_quote($type, '', 'TEXT').')'

Difficile de te dire ce qu'il se passe de manière exacte sans avoir la
base en main et faire du debug, car ce decodage d'URLs arbos est assez
complexe.
Ce que je peux dire c'est que je pense que tu l'utilises de manière
borderline car tu as des segments dans tes URLs mais qui ne
correspondent pas à de la hierarchie d'objets, donc ce n'est pas
totalement surprenant que tu puisses tomber dans des cas pas prévus.

Peut-être ça peut se réparer/compléter pour corriger ce cas, mais à voir.

on pourrait peut-être chercher en 1er l'expression complète 'x/y' et
ensuite les segments ?

Comme tu peux le voir dans la requete pointée au dessus, c'est plus ou moins ce qui est fait, en essayant d'optimiser pour faire ça en une requete, mais ça a été assez pointu à mettre au point...

Cédric

7

Le 25/07/2017 à 11:00, Cédric Morin a écrit :

erational a écrit :

cela marche bien lorsque le 1er segment n'a pas numérique

archive-2016/x
archive-2016/y

cela ne lève pas d'ambiguité

Alors ça vient peut-être du sql_in de la ligne
Connexion · GitLab

qui fait un quote numérique, car je vois que juste la ligne au dessus j'ai fait un quote explicite en 'text'
Il faut peut-être remplacer ce sql_in par un

'(url=' . sql_quote("$type/$url_segment", '', 'TEXT')
. ' OR url=' . sql_quote($type, '', 'TEXT').')'

c'est du SPIP 3.1, ... je n'ai pas pu testé.

Finalement j'ai trouvé une solution plus basique

Dans mon squelette, j'ai surchargé urls/arbo.php, line598, j'ignore les segments
         $url_arbo = array();
         $url_arbo = $url_propre;

http://spip.pastebin.fr/50463

cela a l'air de fonctionner

Difficile de te dire ce qu'il se passe de manière exacte sans avoir la
base en main et faire du debug, car ce decodage d'URLs arbos est assez
complexe.
Ce que je peux dire c'est que je pense que tu l'utilises de manière
borderline car tu as des segments dans tes URLs mais qui ne
correspondent pas à de la hierarchie d'objets, donc ce n'est pas
totalement surprenant que tu puisses tomber dans des cas pas prévus.

Peut-être ça peut se réparer/compléter pour corriger ce cas, mais à voir.

on pourrait peut-être chercher en 1er l'expression complète 'x/y' et
ensuite les segments ?

Comme tu peux le voir dans la requete pointée au dessus, c'est plus ou moins ce qui est fait, en essayant d'optimiser pour faire ça en une requete, mais ça a été assez pointu à mettre au point...

oui ces requêtes sont vraiment poilues

encore merci pour le coup de main !

--
_________________________________________