Accueil > Développement > ToDo > Le piège des URLs « propres »

Le piège des URLs « propres »

vendredi 6 janvier 2006, par Fil

Les URLs propres c’est bien sauf quand ça se coince sur une adresse dont on ne veut pas...

Quelques exemples :
 essai-tab.html (un essai qui s’est coincé)
 ESC-Chambery.html vs. Esc-Saint-Etienne.html (majuscule ou minuscule ?)
 -Les-A-c-coles-.html qui relève de l’indigestion d’utf-8.

Comme le dit Cédric : « oui mais quand tu sais les utiliser c’est bien ; mais faut ruser, c’est vrai ; en fait faudrait une boite de dialogue pour ajuster son url ».

D’accord, mais ça veut bien dire que c’est pas bon, s’il faut une boîte ; à mon avis il faut reprogrammer ça de manière suivante : une table spip_urls qui indique pour chaque url vers quoi ça pointe, et un drapeau pour dire si c’est canonique (l’adresse #URL_ARTICLE) ou un simple alias.

Ce qui donnerait :

URL-de-test => article 1
Super-titre => article 1 (canonique)
Titre-alternatif-utilise-dans-un-vieux-lien => article 1

Avec une interface qui permet de supprimer une URL obsolète ; mais aussi de réaffecter un URL vers un nouvel objet, ou de créer un autre URL de toutes pièces, ou de changer d’url canonique, etc.

Il faut réfléchir aussi au mix articles/rubriques/brèves, car dès lors qu’on aura cette table, on devrait pouvoir faire sauter la distinction des urls-propres actuelles. Et donc par exemple « transformer un article en rubrique » en réaffectant son ancien url à la nouvelle rubrique.

Messages

  • On peut dans la foulée régler aussi le $fond, ce que l’API permet, mais qu’aucune contrib ne fait réellement pour l’instant.

  • Voir la note suivante sur ce sujet dans le gestionnaire de bugs/tickets (en particulier mes remarques 2 et 5).

    Voir aussi http://www.glazman.org/weblog/dotcl....

    Voir en ligne : ticket 45

  • Idéalement, un système d’URL propre (ou une option de celui-ci) présente :

    Je crois que la possibilité d’intégrer cette hiérarchie comme je le vois sur des outils de Weblogs (Wordpress ou Dotclear par exemple), peut être très appréciable d’un point de vue « usabilité » (et peut-être référencement, mais je suis très sensible à l’aspect « usabilité » qui me semble un bon complément d’un « fil d’ariane »).

    Merci Fil en tout cas du travail fait dans le cadre de Spip. Cela aide vraiment beaucoup de personnes à s’exprimer librement sur la toile.

    @mitiés

    Philippe (phdm)

  • La hiérarchie, c’est pas mal, mais ça pose des problèmes pour accéder aux images et aux autres pages du site.

    Et base href n’est pas une bonne solution car ça casse les #ancre (qui se retrouvent relatives au base href et non à la page en cours).

  • si tu mets tout en lien absolus, ça passe. c’est pas qu’une histoire de hierarchie, c’est une histoire de « / » (slash) ...

    Conjointement à cette évolution, il faudrait une option qui transforme tous les liens relatifs en liens absolus. Les filtres existent déjà. Faudrait pouvoir l’appliquer à #DOSSIER_SQUELETTE, les #LOGO_*, les #URL_* ...

  • avec <base href="#URL_SITE_SPIP/#URL_ARTICLE" /> les #ancres sont relatives à l’url de l’article et non plus du site. Mais ça change rien pour les ressources genre img, css et js :(

    Voir en ligne : l’élément BASE

  • Gérer plusieurs URL pour un même contenu, ce serait la Rolls, mais déjà, pouvoir s’épargner des « formats » d’URL différents pour chaque type de contenu, ce serait un bon début.

    Pour ce qui est des exemples du début, je ne comprends pas le problème du premier, le second montre qu’il faut mieux s’en tenir à des minuscules partout, et le troisième n’est qu’une erreur technique.

    Pour ce qui est de la hiérarchie dans l’URL, ça n’a rien de compliqué, il suffit effectivement de mettre les liens en absolu.
    cf http://www.spip-contrib.net/Une-arb...

    Et comme le montre l’URL ci-dessus qui vient de SPIP-Contrib, il ne suffit pas de supprimer des ?, & et autres = pour que ça devienne intelligible...

  • Idéalement, il faudrait aussi pouvoir gérer l’historique :
     pouvoir changer à un moment donné le nom de la page
     continuer à orienter les visiteurs qui viennent d’un moteur de recherche ou d’un lien quelquepart vers la bonne page.

    Cette 2e possibilité se fait soit en mémorisant tous les différents noms utilisés à différents moments, soit sinon par recherche d’affinité de titre (avec algo de comparaison de similarité du titre).

  • Salut,

    Je tombe sur cette page longtemps après qu’elle ait été écrite. Mais voici quand même quelques réactions à cette discussion qui est particulièrement importante, à mon avis.

    une table spip_urls qui indique pour chaque url vers quoi ça pointe

    Un des trucs qu’on perd de vue, il me semble, avec la question des urls propres, c’est que faire appel à MySQL à chaque chargement de page est assez fondamentalement une mauvaise idée et qu’il faut limiter cela au maximum. Tant pour des raisons de charge du serveur (sur les quelques serveurs dont le connais les gestionnaires, mysql est systématiquement le point faible qui est trop sollicité par rapport à l’équilibre de la machine) que pour faire en sorte que le site reste accessible même quand le serveur mysql est planté (ce que le cache de spip permet en principe).

    Je me demande s’il ne serait pas intéressant de chercher du coté du module RewriteMap d’Apache pour stocker les données des redirections non pas dans une table mysql mais directement dans les instructions données à Apache.

    La hiérarchie, c’est pas mal, mais ça pose des problèmes pour accéder aux images et aux autres pages du site.

    Oui ! Trois fois oui. Surtout avec la 1.9 qui renvoie des urls tout bizarres, absolus, mais mal écrits.

    La plupart de mes sites ont des urls du type domaine.tld/rep/20060607_page.html (ou de nombreuses variantes) et je me suis cassé les dents à chercher une solution globale et simple à la question des urls. En attendant, je filtre tout (les logos, images,...) et mon fichier de génération d’url renvoie tout en absolu.

    Dans le même genre, il y a les sites qui utilisent plusieurs domaines pour un seul SPIP (par exemple les sites multilingues qui utilisent un domaine différent pour chaque langue — pour les sites officiels en Belgique, par exemple, ça doit probablement être légalement obligatoire), pour lesquels la gestion des urls est aussi un véritable casse-tête.

    Gérer plusieurs URL pour un même contenu, ce serait la Rolls, mais déjà, pouvoir s’épargner des « formats » d’URL différents pour chaque type de contenu, ce serait un bon début.

    Plusieurs urls pour un même contenu, c’est pas une bonne idée à mon avis, voire une franchement très mauvaise idée. Il faut que l’indexation des pages se fasse sur une seule url pour être efficace. Plusieurs urls pour une même page, ça fatigue aussi inutilement les systèmes de caches (aussi bien celui de spip que celui d’un proxy intermédiaire que celui du navigateur). Sans parler des confusions humaines que ça peut engendrer. Il faudrait donc que tous les aliasses ne renvoient pas directement le contenu, mais passent par une instruction RedirectPermanent.

    Mes deux sous ;

    Voir en ligne : Des Bulles

  • faire appel à MySQL à chaque chargement de page est assez fondamentalement une mauvaise idée

    Oui mais justement les inc-urls n’ont pas ce problème car le cache est basé sur l’URL.

    la 1.9 qui renvoie des urls tout bizarres, absolus, mais mal écrits.

    Fais un ticket détaillé, je ne sais pas à quoi tu fais référence

  • Salut,

    Oui mais justement les inc-urls n’ont pas ce problème car le cache est basé sur l’URL.

    Ah oui, juste. Autant pour moi.

    Fais un ticket détaillé, je ne sais pas à quoi tu fais référence

    C’est pas réellement un bug, c’est juste le fait que SPIP était plus facilement adaptable à des urls abrorescentes avant la 1.9. Ceci concerne au moins les boutons d’admin : le lien vers la page admin correspondante était auparavant du type « ecrire/... » (il était donc assez facile de rajouter un slash avant l’url pour les faire partir de la racine). Il est maintenant du type "http://domaine.tld/repertoire/ecrire/.. si on se trouve dans le répertoire »repertoire", ce qui oblige à filtrer ou à faire des rewriterule compliquées. Il serait sans doute possible et préférable, si l’on veut que les liens des boutons d’admin soient en absolu, de les faire reposer sur l’url du site plutôt que sur l’url de la page courante. Ils seraient bons dans tous les cas.

    François

    PS au webmestre du site : Il manque un « width : 100% ; » sur le textarea dans la feuille de style du blog : le champ d’édcriture est tout rikiki.

    Voir en ligne : Des Bulles

  • La boîte pour ajuster son URL est restée à l’étatde projet ? Elle m’est précieuse sur Dotclear par exemple. Le titre de l’article n’est pas toujours pertinent pour une URL.

Un message, un commentaire ?

Qui êtes-vous ?
Se connecter
Votre message

Ce formulaire accepte les raccourcis SPIP [->url] {{gras}} {italique} <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.