[spip-dev] Paramétrage des urls propres

Dev
1

Bonsoir,

Je suis en train de tester le nouveau système d'urls, qui semble
vraiment très bien. Vu que ça n'a pas l'air d'être compatible avec les
vieux inc-urls.php, j'en profite pour réécrire le schéma d'urls de
certains sites dont je m'occupe, ce qui m'amène à me poser quelques
questions et à formuler quelques suggestions.

1. Quand plusieurs urls correspondent à un même objet, l'objet est
atteignable indifféremment depuis ces différentes urls. Ne serait-il pas
préférable de forcer la redirection vers une url de référence unique ?
Avantages : meilleure indexation dans les moteurs de recherche,
optimisation du cache de SPIP, limitation du risque de doublon dans les
bases de données tierces qui utilisent l'url pour garantir l'unicité de
références documentaires.

2. Serait-il possible de rendre surchargeables les fonctions
generer_url_article(); et suivantes (sans modifier le fichier
ecrire/url/propres.php) ?

3. Serait-il possible de permettre par défaut un peu plus de
personnalisation des urls propres : notamment permettre de forcer les
urls en minuscules, choisir le séparateur (actuellement "-" par défaut),
déterminer la longueur maximale des urls (qui dépend fortement de la
longueur du domaine, si l'on veut rester en dessous de 80 caractères
pour la longueur totale de l'url). L'ajout de trois constantes
(_URL_PROPRES_CASSE, _URL_PROPRES_SEPARATEUR, _URL_PROPRES_LONGUEUR) aux
lignes 122 et suivantes de ecrire/urls/propres.php devrait faire
l'affaire. Un autre truc très utile serait de pouvoir passer un
paramètre optionnel "date=TRUE" à la fonction _generer_url_propre qui,
si l'objet est un article, préfixerait l'url propre avec la date au
format AAAAMMJJ.

4. Il ne semble pas possible de gérer une arborescence virtuelle à via
ce nouveau système d'urls propres (par exemple pour faire des urls comme
"tags/blabla.html" ou "articles/20070909_un_article.html") ? Y a-t-il
une raison à cette limitation ?

Merci de vos lumières

François

2

Bonsoir,

Je suis en train de tester le nouveau système d'urls, qui semble
vraiment très bien. Vu que ça n'a pas l'air d'être compatible avec les
vieux inc-urls.php,

je ne comprends pas de quelle compatibilité il s'agit.

j'en profite pour réécrire le schéma d'urls de
certains sites dont je m'occupe, ce qui m'amène à me poser quelques
questions et à formuler quelques suggestions.

1. Quand plusieurs urls correspondent à un même objet, l'objet est
atteignable indifféremment depuis ces différentes urls. Ne serait-il pas
préférable de forcer la redirection vers une url de référence unique ?
Avantages : meilleure indexation dans les moteurs de recherche,
optimisation du cache de SPIP, limitation du risque de doublon dans les
bases de données tierces qui utilisent l'url pour garantir l'unicité de
références documentaires.

Bonnes remarques, mais je ne suis pas sûr que ce soit implémentable en étant sûr quanc'est opportun de le faire.

2. Serait-il possible de rendre surchargeables les fonctions
generer_url_article(); et suivantes (sans modifier le fichier
ecrire/url/propres.php) ?

ce système est déjà une surcharge, on pourrait tronçonner ce fichier pour ne surcharger que ce qui gene mais à ce compte là on va se retrouver avec autant de fichier que de fonctions dans SPIP, il faut fixer une limite.

3. Serait-il possible de permettre par défaut un peu plus de
personnalisation des urls propres : notamment permettre de forcer les
urls en minuscules, choisir le séparateur (actuellement "-" par défaut),
déterminer la longueur maximale des urls (qui dépend fortement de la
longueur du domaine, si l'on veut rester en dessous de 80 caractères
pour la longueur totale de l'url). L'ajout de trois constantes
(_URL_PROPRES_CASSE, _URL_PROPRES_SEPARATEUR, _URL_PROPRES_LONGUEUR) aux
lignes 122 et suivantes de ecrire/urls/propres.php devrait faire
l'affaire. Un autre truc très utile serait de pouvoir passer un
paramètre optionnel "date=TRUE" à la fonction _generer_url_propre qui,
si l'objet est un article, préfixerait l'url propre avec la date au
format AAAAMMJJ.

meme remarque.

4. Il ne semble pas possible de gérer une arborescence virtuelle à via
ce nouveau système d'urls propres (par exemple pour faire des urls comme
"tags/blabla.html" ou "articles/20070909_un_article.html") ? Y a-t-il
une raison à cette limitation ?

de nouveau je ne comprends pas ce qui était possible avant et ne l'est plus.

Committo,Ergo:Sum

3

Bonsoir,

> Je suis en train de tester le nouveau système d'urls, qui semble
> vraiment très bien. Vu que ça n'a pas l'air d'être compatible avec les
> vieux inc-urls.php,

je ne comprends pas de quelle compatibilité il s'agit.

La présence du fichier inc-urls.php à la racine de SPIP provoque un bug
(doubles déclarations de fonctions, au moins). Je n'ai pas approfondi vu
que ce truc était déjà obsolète dans la précédente version stable; j'en
ai profité pour adapter mes scripts au nouveau système.

> 1. Quand plusieurs urls correspondent à un même objet, l'objet est
> atteignable indifféremment depuis ces différentes urls. Ne serait-
> il pas préférable de forcer la redirection vers une url de référence
> unique ? Avantages : meilleure indexation dans les moteurs de
> recherche, optimisation du cache de SPIP, limitation du risque de
> doublon dans les bases de données tierces qui utilisent l'url pour
> garantir l'unicité de références documentaires.

Bonnes remarques, mais je ne suis pas sûr que ce soit implémentable
en étant sûr quand c'est opportun de le faire.

Dans quels cas est-ce que ça pourrait poser problème ?

> 2. Serait-il possible de rendre surchargeables les fonctions
> generer_url_article(); et suivantes (sans modifier le fichier
> ecrire/url/propres.php) ?

ce système est déjà une surcharge, on pourrait tronçonner ce fichier
pour ne surcharger que ce qui gene mais à ce compte là on va se
retrouver avec autant de fichier que de fonctions dans SPIP, il faut
fixer une limite.

ok.

> 4. Il ne semble pas possible de gérer une arborescence virtuelle à via
> ce nouveau système d'urls propres (par exemple pour faire des urls
> comme "tags/blabla.html" ou "articles/20070909_un_article.html") ? Y
> a-t-il une raison à cette limitation ?

de nouveau je ne comprends pas ce qui était possible avant et ne
l'est plus.

C'est quelque chose qui n'a jamais été simple à faire dans SPIP
(d'autant plus que ça pose pleins de problèmes pour la gestion des liens
vers les images, les forums, etc) donc il n'y a aucune perte de
compatibilité. C'est cependant quelque chose que je fais assez
régulièrement, pour différentes raisons (notamment pour contrôler
facilement l'indexation par répertoire virtuel via un robots.txt) en
bidouillant pour arriver à mes fins. Je me disais simplement que le
nouveau système étant peut-être l'occasion de faciliter la gestion d'un
système d'urls non plat. Par exemple, pour un site bilingue, j'aimerais
avoir les urls suivantes pour les deux versions d'une page de contact :
  en/contact
  fr/contact
À moins de l'écrire "en dur" dans .htaccess, c'est quelque chose qu'il
n'est pas possible de faire via le système d'urls propres de SPIP, pour
autant que j'en sache. Autre exemple : les urls d'une revue. Par exemple
ceci : <archives/2007/07/1111.html>. Là, ça marche, mais ce serait plus
joli en remplaçant le "1111" par quelque chose de plus significatif.
Mais bon, on s'est débrouillé jusqu'ici, on va continuer à le faire. Pas
de souci.

bonne fin de soirée,

François

4

C'est quelque chose qui n'a jamais été simple à faire dans SPIP

Ca reste en projet, évidemment, et avec la nouvelle table unifiée je
pense que ce sera beaucoup plus facilement faisable.

(d'autant plus que ça pose pleins de problèmes pour la gestion des liens
vers les images, les forums, etc)

voilà, c'est ça le problème ; un début de solution se trouve dans le
$profondeur_url, mais à vue de nez il y a deux ou trois jours de
travail pour que ce soit totalement fiable.

-- Fil

5

4. Il ne semble pas possible de gérer une arborescence virtuelle à via
ce nouveau système d'urls propres (par exemple pour faire des urls
comme "tags/blabla.html" ou "articles/20070909_un_article.html") ? Y
a-t-il une raison à cette limitation ?

de nouveau je ne comprends pas ce qui était possible avant et ne
l'est plus.

C'est quelque chose qui n'a jamais été simple à faire dans SPIP

Ah bon ?

Nous le faisons pourtant depuis des années :
<http://www.clever-age.com/veille/blog/tags/spip/&gt;

Je n'ai pas encore regardé les nouveautés côté URL propres -- ou plutôt capacités de redéfinition d'URL, mais j'espère que tous mes sites qui utilisent leurs propres définitions resteront opérationnels....

-Nicolas

6

Nicolas Hoizey a écrit :

4. Il ne semble pas possible de gérer une arborescence virtuelle à via
ce nouveau système d'urls propres (par exemple pour faire des urls
comme "tags/blabla.html" ou "articles/20070909_un_article.html") ? Y
a-t-il une raison à cette limitation ?
        

de nouveau je ne comprends pas ce qui était possible avant et ne
l'est plus.
      

C'est quelque chose qui n'a jamais été simple à faire dans SPIP
    
Ah bon ?

Nous le faisons pourtant depuis des années :
<http://www.clever-age.com/veille/blog/tags/spip/&gt;
  

il est dommage que vous n'en fassiez pas profiter la communauté en packageant ca proprement et en le rendant pret à l'emploi, cela serait sans nul doute utile à beaucoup de monde.

Cedric

7

Nous le faisons pourtant depuis des années :
<http://www.clever-age.com/veille/blog/tags/spip/&gt;

il est dommage que vous n'en fassiez pas profiter la communauté en packageant ca proprement et en le rendant pret à l'emploi, cela serait sans nul doute utile à beaucoup de monde.

Comme tu peux le voir dans l'URL ci-dessus, il n'y a pas que l'arborescence des rubriques -- qui s'arrête à "blog", il y a aussi une gestion des mots clefs. C'est difficilement généralisable.

Je ne vois de toute façon vraiment pas la difficulté qu'il y a à ajouter une arborescence dans les URL, vu qu'on connaît l'id des éléments dans les fonctions de génération d'URL, et que donc on peut récupérer leur hiérarchie.

Mais bon, je ferais peut-être un court article sur notre blog pour expliquer le principe de base.

-Nicolas

8

Nicolas Hoizey a écrit :

Nous le faisons pourtant depuis des années :
<http://www.clever-age.com/veille/blog/tags/spip/&gt;

il est dommage que vous n'en fassiez pas profiter la communauté en packageant ca proprement et en le rendant pret à l'emploi, cela serait sans nul doute utile à beaucoup de monde.
    
Comme tu peux le voir dans l'URL ci-dessus, il n'y a pas que l'arborescence des rubriques -- qui s'arrête à "blog", il y a aussi une gestion des mots clefs. C'est difficilement généralisable.
  

C'est l'essence meme du travail de partage et de 'reversement' que de rendre suffisament générique (disons au moins pour 80% des utilisateurs) et simple d'utilisation un petit bout de code qu'on a fait dans son coin pour un besoin perso. Avec eventuellement des extensibilité qui permettent de traiter les cas tordus (dont en general le cas perso fait partie justement :p)

Je ne vois de toute façon vraiment pas la difficulté qu'il y a à ajouter une arborescence dans les URL, vu qu'on connaît l'id des éléments dans les fonctions de génération d'URL, et que donc on peut récupérer leur hiérarchie.

Mais bon, je ferais peut-être un court article sur notre blog pour expliquer le principe de base.
  

Il me semble que le principe de base est clair, et ce qui manque a tout le monde c'est un outil utilisable, pratique et fonctionnel.

Quand je parlais de faire profiter la communauté, c'est bien de cela qu'il s'agissait.
Et je voyais la une jolie occasion pour clever age de reverser un savoir faire utile a tous
Mais c'est pas grave, on fera comme d'habitude.
Cedric

9

Nicolas Hoizey a écrit :

Je ne vois de toute façon vraiment pas la difficulté qu'il y a à ajouter une arborescence dans les URL, vu qu'on connaît l'id des éléments dans les fonctions de génération d'URL, et que donc on peut récupérer leur hiérarchie.

S'il n'y a pas de difficulté pour toi, alors que c'est pas livré en standard
et qu'il y a des difficultés à faire de même pour beaucoup d'autres utilisateurs,
alors ta contribution sera d'autant plus utile !

Et le fait que tu es à l'aise avec le sujet, permet d'espé&rer que la doc
sera de qualité.
Donc banco, vraiment, ce sera apprécié !

Cordialement,
JLuc

10

C'est l'essence meme du travail de partage et de 'reversement' que de rendre suffisament générique (disons au moins pour 80% des utilisateurs) et simple d'utilisation un petit bout de code qu'on a fait dans son coin pour un besoin perso. Avec eventuellement des extensibilité qui permettent de traiter les cas tordus (dont en general le cas perso fait partie justement :p)

La différence entre notre code et les URL propres disponibles par défaut depuis longtemps, c'est en gros cela :

  function arborescence($id_rubrique) {
    if ($id_rubrique == 0) {
      $url = '/';
    } else {
      $result = spip_query("SELECT id_parent, titre FROM spip_rubriques WHERE id_rubrique=$id_rubrique");
      $row = spip_fetch_array($result);
      $url = arborescence($row['id_parent']).text2url($row['titre']).'/';
    }
    return $url;
  }

Je ne vois de toute façon vraiment pas la difficulté qu'il y a à ajouter une arborescence dans les URL, vu qu'on connaît l'id des éléments dans les fonctions de génération d'URL, et que donc on peut récupérer leur hiérarchie.

Mais bon, je ferais peut-être un court article sur notre blog pour expliquer le principe de base.

Il me semble que le principe de base est clair, et ce qui manque a tout le monde c'est un outil utilisable, pratique et fonctionnel.

Il me semblait que c'était le but des nouvelles URL propres d'Emmanuel, avec des constantes pour configurer la « tête » de ces URL, justement.

Ajouter la fonction ci-dessus avec une constante pour indiquer que l'on souhaite utiliser une arborescence devrait suffire, non ?

Quand je parlais de faire profiter la communauté, c'est bien de cela qu'il s'agissait.
Et je voyais la une jolie occasion pour clever age de reverser un savoir faire utile a tous

Ce que nous faisons bien volontiers régulièrement, évidemment.

Mais c'est pas grave, on fera comme d'habitude.

C'est à dire ?

-Nicolas

11

Nicolas Hoizey a écrit :

C'est l'essence meme du travail de partage et de 'reversement' que de rendre suffisament générique (disons au moins pour 80% des utilisateurs) et simple d'utilisation un petit bout de code qu'on a fait dans son coin pour un besoin perso. Avec eventuellement des extensibilité qui permettent de traiter les cas tordus (dont en general le cas perso fait partie justement :p)
    
La différence entre notre code et les URL propres disponibles par défaut depuis longtemps, c'est en gros cela :

  function arborescence($id_rubrique) {
    if ($id_rubrique == 0) {
      $url = '/';
    } else {
      $result = spip_query("SELECT id_parent, titre FROM spip_rubriques WHERE id_rubrique=$id_rubrique");
      $row = spip_fetch_array($result);
      $url = arborescence($row['id_parent']).text2url($row['titre']).'/';
    }
    return $url;
  }
  

Oui enfin, pour faire une analogie avec un plugin qui existe,
je te dis 'ça serait bien que tu fasses profiter tout le monde en packageant ça dans un plugin qui gère facilement les restrictions d'acces sur un site pour que ca soit facile d'emploi pour tous'

et tu me réponds

'c'est facile, en gros il suffit de faire <?php if($GLOBALS['auteur_session']['statut']=='0minirezo') { ?> dans le squelette'

Je pense que tu vois la différence entre les deux non ? D'ailleurs je note que tu as préféré utiliser le plugin que mettre des bouts de code perso partout dans tes squelettes pour faire la meme chose.

  

Je ne vois de toute façon vraiment pas la difficulté qu'il y a à ajouter une arborescence dans les URL, vu qu'on connaît l'id des éléments dans les fonctions de génération d'URL, et que donc on peut récupérer leur hiérarchie.

Mais bon, je ferais peut-être un court article sur notre blog pour expliquer le principe de base.

Il me semble que le principe de base est clair, et ce qui manque a tout le monde c'est un outil utilisable, pratique et fonctionnel.
    
Il me semblait que c'était le but des nouvelles URL propres d'Emmanuel, avec des constantes pour configurer la « tête » de ces URL, justement.

Ajouter la fonction ci-dessus avec une constante pour indiquer que l'on souhaite utiliser une arborescence devrait suffire, non ?
  

je ne sais pas, je n'ai pas regardé en détail, et toi tu avais l'air de connaître le sujet.

  

Quand je parlais de faire profiter la communauté, c'est bien de cela qu'il s'agissait.
Et je voyais la une jolie occasion pour clever age de reverser un savoir faire utile a tous
    
Ce que nous faisons bien volontiers régulièrement, évidemment.

Mais c'est pas grave, on fera comme d'habitude.
    
C'est à dire ?
  

On prendra sur nos soirs, nuits et week-end pour produire une fonctionnalité prête à l'emploi dont on a pas forcément besoin personnellement mais qui sera utile à beaucoup.
Mais ça sera surement au détriment d'une autre fonctionnalité, le temps n'étant pas inépuisable.

Cédric

12

Bonsoir,

cedric.morin@yterium.com a écrit :

Nicolas Hoizey a écrit :

4. Il ne semble pas possible de gérer une arborescence virtuelle
à via
ce nouveau système d'urls propres (par exemple pour faire des urls
comme "tags/blabla.html" ou "articles/20070909_un_article.html") ? Y
a-t-il une raison à cette limitation ?
        

de nouveau je ne comprends pas ce qui était possible avant et ne
l'est plus.
      

C'est quelque chose qui n'a jamais été simple à faire dans SPIP
    

Ah bon ?

Nous le faisons pourtant depuis des années :
<http://www.clever-age.com/veille/blog/tags/spip/&gt;
  

il est dommage que vous n'en fassiez pas profiter la communauté en
packageant ca proprement et en le rendant pret à l'emploi, cela serait
sans nul doute utile à beaucoup de monde.

J'ai fait un plugin qui fait ce genre de chose. Je l'ai mis en ligne
seulement aujourd'hui (le temps de mettre tout ça dans mon propre repo
SVN etc ...) bien qu'écrit il y a plus d'un an.

http://www.malguy.net/resources/spip-plugin-url-hierarchiques.html

J'y indique que ce plugin en utilise un autre également dispo sur le
site (spip-plugin-divers), ainsi que deux patchs à appliquer sur la
version 1.9.2b (je n'ai pas encore préparé de patch pour la version SVN
d'SPIP) pour corriger des petits soucis lorsque les URLS sont en
hiérarchiques. Je n'ai d'ailleurs sans doute pas rencontrer tous les cas
à problème possibles.

Il faut encore que je signale la disponibilité de ces plugins sur
SPIP-Contrib (si j'ai bien compris), donc oui, tout n'est pas encore
fait, mais les plugins sont convenablement empaquetés pour leur utilisation.

Cordialement,