Le Hollandais Volant

Pourquoi je ne mets pas d’URL Rewriting sur mon site

Mercredi 16 janvier 2013

no-rage-face.png
On me demande régulièrement si je vais un jour mettre de l’URL rewriting sur mon blog, j’ai toujours répondu non. Voilà pourquoi.

L’URL rewriting, pour un blog, c’est ce qui permet de faire des URL plus courtes, plus lisibles. On passerait par exemple de ça :
http://lehollandaisvolant.net/?d=2011/11/17/21/59/23-la-terre-tourne-dans-tous-les-sens
à ça (masquant les informations utiles au serveur et pas au lecteur) :
http://lehollandaisvolant.net/la-terre-tourne-dans-tous-les-sens

Si je ne veux pas de ce genre de choses, c’est principalement pour cette question : pourquoi faire ?
Qui peut bien se soucier de la forme de l’URL, à quoi ça sert qu’elle soit jolie ou pas ? Pourquoi vouloir faire à tout prix des URL courtes ? Pourquoi vouloir masquer les informations qui expliquent le fonctionnement de l’Internet et du Web ?

La forme de l’URL n’est pas importante : elle est destinée au navigateur, pas au lecteur ! Par ailleurs, vive le copier-coller, hein : qui recopie les url à la main, ici ?

Les URL courtes ne servent strictement à rien : autant utiliser la balise de lien, avec un texte pour cliquer (coucou, Twitter !). Quant aux raccourcissements, n’en parlons pas.

Masquer les informations au serveur ? Pas une bonne chose non plus… C’est comme cette manie de cacher l’ancre et le protocole dans les navigateurs (coucou Opera, Chrome, Firefox !). Si vous ne voulez pas voir l’ancre, ou le protocole utilisé dans une URL, alors masquez la barre d’URL directement ! En afficher seulement une partie ne rime à rien…

Autre chose : utiliser l’URL rewriting nécessite d’avoir une liste de toutes les correspondances entre les URL courtes et les URL longues sur son serveur. Si y’en a 5, ça va. Si y’en a 5000, c’est déjà autre chose : ça ralentit tout l’ensemble et c’est bof pour la maintenance…

Non sérieux, je ne vois pas le besoin ici.

blop : #

Pour accéder à certaines pages plus rapidement, c'est quand même pratique. Pour ma part, un /links plutôt éviterait de taper 6 caractères supplémentaires (/?mode=links) ou de cliquer sur le lien depuis la page d'accueil.

seb : #

Quand je vois le nombre de gens aller sur Google, taper le nom du site et cliquer sur le premier lien au lieux de taper l'adresse du site internet (ou même que le début avec l'autocompletion par le navigateur grâce à l'historique), c'est sûr qu'on s'en fou un peu de la tête de l'url, la plus part des gens ne la regarde même pas.

Le Hollandais Volant : #

@®om : mouais… Je vois bien ce qu’il veut dire, mais encore une fois : l’utilité là dedans ?

@qwerty : ça ne changera rien à la rétrocompatibilité : le cœur du CMS fonctionne avec l’URL longue…
Si on lui donne une URL courte (de l’ancienne ou de la nouvelle version), il essaiera de la transformer en sa version longue.

Dans ce cas, l’URL rewriting pour rendre compatible les vieux URL est utile… Mais ça les rendra pas plus belles.

Sinon, ouais, cet article est un article que j’ai débuté en 2011. Vous allez en voir quelques autres, des articles écrits il y a longtemps mais publiés seulement maintenant : j’en ai une bonne cinquantaine en réserve, que je n’ai jamais fini faute de temps…


@blop : utilises un navigateur digne de ce nom, qui permette de faire ça directement, nativement et facilement ;-).
Perso je tape "gg" pour avoir Google ("gg requête" pour une recherche dans Google) ; "linx" pour ajouter un lien à mes liens ; "op" pour mes mails chez myopera ; "y" pour youtube ("y requête" pour une recherche sur youtube) ; "w requête" pour wikipédia, etc.

Autrement, ton exemple est pas mal : je suis d’accord pour ton cas, ok : des URL comme ça y’en aura jamais 500. D’ailleurs j’ai quelques pages comme ça (dont ma page de contact), même si moi c’est plutôt la redirection et non la ré-écriture.

Mais pour tous les articles, bof…

(mais rassurez-vous : quelqu’un est en train de développer un patch pour Blogotext, avec cette fonctionnalité :p)

Luc : #

L'utilité d'une "belle" url, c'est justement de se détacher un peu des aspects techniques et architecturaux. Par exemple, si tu changes d'appli ou que tu restructures. Une url simple (je préfère "simple" à "belle") est plus maintenable non ?

Un autre intérêt, plus vicieux, vient du fait que google et ses potes utilisent les mots de l'url dans leur indexation. Dans ton cas, pas de souci. Mais avec les id de certains systèmes, c'est moyen.

Tu crois vraiment que l'url-rewriting ralenti significativement le serveur ? Je vais tester ça ;)

Cela dit, tu as raison, on s'en tape que'une url soit "belle"... :)

Le Hollandais Volant : #

@Luc : ok, donc c’est que mon Blogotext fait déjà un truc assez propre (bon toutou), et que j’en vois pas l’utilité pour moi…


Tu crois vraiment que l'url-rewriting ralenti significativement le serveur ? Je vais tester ça ;)


Significativement, je sais pas…

MESCANEFEUX : #

@seb : +1


Quand je vois le nombre de gens aller sur Google, taper le nom du site et cliquer sur le premier lien au lieux de taper l'adresse du site internet

Gilles : #

Perso j'aime les URLs compréhensible et en effet, je tape souvent mes URL genre sebsauvage.net/links et j'aimerais bien lehollandaisvolant/links ;)
'fin je m'en fiche mais bon quand c’est retenable de tête + court bah c'est mieux je trouve.

Guenhwyvar : #

@Le Hollandais Volant :


Mais pour tous les articles, bof…


Ça sert quand on tombe sur des liens, avec le titre dans l'URL on sait globalement de quoi ça va parler avant d'aller dessus. Et c'est bien pour ça que même si t'as pas de « vrai » rewriting, tu mets toi aussi des infos inutiles techniquement dans ton URL, sinon ce serait juste http://lehollandaisvolant.net/index.php?d=2013/01/16/14/09/.

Quentin : #

Pourquoi génères-tu un HTML propre, ou que tu y mets des commentaires ? Il y a pourtant moins de gens qui lisent le code source d'une page que ceux qui en regardent l'URL. Ce n'est qu'une question d'esthétique et d'utilité.

Le but n'est pas d'obligatoirement utiliser de l'URL rewriting mais d'avoir des URLs pratiques, compréhensibles et si possible belles pour la simple et bonne raison qu'une partie des utilisateurs d'internet utilisent ces URLs : ils les écrivent, les modifient et les mémorisent pour naviguer. On peut changer d'article sur Wikipedia sans liens car l'URL d'un article est en général devinable (par exemple, il m'arrive de le faire pour éviter une recherche). Il est aussi plus agréable de pouvoir changer la langue d'un site depuis l'URL ou de trouver la page "parent" d'une autre (si je suis sur /faq/question1, je sais que l'index de la faq sera sur /faq/, pas besoin de chercher un lien sur la page).

L'intérêt pour ce blog ? Les URLs ne sont pas horribles et personne n'essaie d'arriver sur un article en tapant son adresse complète. Par contre tu pourrais gagner en utilité en affichant la catégorie dans l'URL avant le nom de l'article, par exemple /réflexions/11-pourquoi... : il serait alors plus facile d'accéder aux articles de cette catégorie en supprimant simplement le nom de l'article. /réflexions/ parent de /réflexions/11-pourquoi... est nettement plus logique que index.php?tag=réflexions parent de index.php?d=2013/01/16/14/09/11-pourquoi...

Il est par contre inutile d'activer de l'URL rewriting pour passer de /?d=2013/01/16/14/09/11-pourquoi à /2013/01/16/14/09/11-pourquoi.

blop : #

@Le Hollandais Volant :


@blop : utilises un navigateur digne de ce nom, qui permette de faire ça directement, nativement et facilement ;-).
Perso je tape "gg" pour avoir Google ("gg requête" pour une recherche dans Google) ; "linx" pour ajouter un lien à mes liens ; "op" pour mes mails chez myopera ; "y" pour youtube ("y requête" pour une recherche sur youtube) ; "w requête" pour wikipédia, etc.


C'est vrai que c'est pratique cette fonctionnalité d'Opéra, je ne la connaissais pas (je ne l'utilise qu'en troisième choix). Après une URL courte, c'est essentiellement pour que ça soit facile à retenir, et donc "transportable" ; chez soit il y a toujours les bookmarks ou le flux RSS.

bajazet : #

/me part se cacher. Je suis entrain de faire une règle pour raccourcir les liens de blogo du genre bajazet.fr/blog/2012/01/01/titre_article.html. J'hésite encore entre 2012/01/01 et 2012_01_01. Et raccourcir une URL te rajoute une sécurité. Impossible de savoir si 2012/ est un répertoire, comment est appelée la page et ça fait croire à un contenu statique. Perso je préfère.

Le Hollandais Volant : #

@bajazet : la sécurité n’est que relative. Un bon hacker n’y verra que du feu…

@Quentin :


Le but n'est pas d'obligatoirement utiliser de l'URL rewriting mais d'avoir des URLs pratiques



Ben je ne vois pas en quoi ce que j’ai maintenant est peu pratique.
C’est long, mais pas incompréhensible.
Quant aux « faux » dossier, sur les sites, je les utilise aussi. Mais il faut s’adapter à chaque site après…


est nettement plus logique que index.php?tag=réflexions parent de index.php?d=2013/01/16/14/09/11-pourquoi...


Justement, la page ?tag=réflexions n’est pas le parent de index.php?d=2013/01/16/14/09/11-pourquoi…

C’est pas moins pratique, c’est juste différent. Et plus logique : les /tag/page/, pour moi, c’est un dossier, alors que ?tag=sciences, c’est clairement une option, un message qu’on transmet au serveur et qui va modifier la requête.


Il est aussi plus agréable de pouvoir changer la langue d'un site depuis l'URL ou de trouver la page "parent" d'une autre (si je suis sur /faq/question1, je sais que l'index de la faq sera sur /faq/, pas besoin de chercher un lien sur la page).


Ouais, c’est logique car c’est en général comme ça que ça se passe : /faq/, le dossier et les pages 1, 2, 3… à l’intérieur. En tout cas, je le fais comme ça car naturel…

Mais si tu veux rechercher un article contenant "bonjour", avec un tag "salut", daté de "2013/01", le faire avec les URL ré-écrite, c’est de la folie…
Alors qu’avec les paramètres ça serait (pas implémenté ici) : ?tag=salut&d=2013/01&q=bonjour

Ouais, ça demande quelques connaissances sur le fonctionnement des sites web, mais ça, ça n’a jamais tué personne.

Guillaume : #

@bajazet :

Pour des raisons de SEO, je te conseille de préférer 2012_01_01. D'ailleurs avoir de belles urls ou non influe sur le référencement d'une page.

schoewilliam : #

@Le Hollandais Volant :


@blop : utilises un navigateur digne de ce nom, qui permette de faire ça directement, nativement et facilement ;-).
Perso je tape "gg" pour avoir Google ("gg requête" pour une recherche dans Google) ; "linx" pour ajouter un lien à mes liens ; "op" pour mes mails chez myopera ; "y" pour youtube ("y requête" pour une recherche sur youtube) ; "w requête" pour wikipédia, etc.



Mignon le petit troll, mais Firefox le fait, malgré que tu ne le considères pas comme un « navigateur digne de ce nom ». Je suis effectivement adepte du « y <mots-clefs> » pour youtube ou « w <mots-clefs> » pour Wikipedia.


Autrement, je comprends ton raisonnement, bien que, comme dit plus haut, il y a des raisons de confort à prendre en compte.

MrKooky : #

Je sais pas si ça a été dit (la flemme de tout lire), mais l'URL rewriting c'est plus user-friendly et SEO-friendly. A toi de voir si ça t'importe ou pas ;)

Kevin : #


Pourquoi vouloir masquer les informations qui expliquent le fonctionnement de l’Internet et du Web ?



ah je ne suis pas d'accord avec ça, une URL c'est une URL, ça ne cache pas le fonctionnement d'internet !
Au contrainte, une URL 'simple' permet aux utilisateurs (ok, aux utilisateurs avancés) de se déplacer directement avec les urls, sans (avec un peu moins) de reverse engineering:

> http://lehollandaisvolant.net/index.php?q=toto --> http://lehollandaisvolant.net/search/toto
> http://lehollandaisvolant.net/index.php?d=2013/01/16 --> http://lehollandaisvolant.net/date/2013/01/16

là c'est trivial, mais là:

> http://www.easyvols.org/avionfr/mev2/results.jsp?type=1&departAllerData=v:5580|c:PAR|t:Paris&arriveeAllerData=v:2181|c:FDF|t:Fort-de-France&dateAller=25/01/2013&dateRetour=01/02/2013&paxAdultes=1&paxEnfants=0&paxBebes=0&classe=1&departAllerData2=a:5829|c:CDG|t:Paris-Charles-de-Gaulle#/AD:IN|CDG|/ev_SID:7F12E3019FA2B0AA6BD22254398FAB3F.bresil/esvId:135841003691110277039015681036.bresil/

ou là:

> https://www.google.fr/search?q=avion.fr&hl=en&safe=active&client=firefox-a&hs=cY6&tbo=d&rls=org.mozilla:en-US:unofficial&biw=1276&bih=863&source=lnms&sa=X&ei=obH3UKHICYfasgazzIHQAQ&ved=0CAkQ_AUoAA

comment tu fais passer l'interface en français ? `&hl=fr`

®om : #


Ben je ne vois pas en quoi ce que j’ai maintenant est peu pratique.



Dans la mesure du possible, l'URL doit contenir les informations pertinentes et rester simple (donc courte).
Par exemple, dans ton URL :
http://lehollandaisvolant.net/index.php?d=2013/01/16/14/09/11-pourquoi-je-ne-met-pas-durl-rewriting-sur-mon-site
Le 2013 pour l'année et 01 pour le mois sont très utiles (ça permet de savoir si l'article est récent ou non). 16, le jour, pourquoi pas. Mais l'heure, les minutes et les secondes n'apportent aucune information pertinente au lecteur (on s'en fout que tu l'aies posté à 14h10mn38s au lieu de 14h09mn11s). Pourquoi pas mettre les millisecondes aussi ?

Par contre, le titre dans l'URL est utile : on sait tout de suite de quoi ça parle. Bon, par contre, tu as la même faute de conjugaison dans ton url que dans ton titre ;-)

Sbgodin : #

Hello,

Je suis en train d'implémenter la réécriture d'url, en accord avec notre hôte. Elle est d'ailleurs déjà en production sur mon site, bien qu'en version alpha.

Que pensez-vous des changements d'url suivants :

http://lehollandaisvolant.net/?d=2013/01/16/14/09/11-pourquoi-je-ne-met-pas-durl-rewriting-sur-mon-site
http://lehollandaisvolant.net/2013/01/16/14/09/11-pourquoi-je-ne-met-pas-durl-rewriting-sur-mon-site

http://lehollandaisvolant.net/index.php?tag=r%C3%A9flexions
http://lehollandaisvolant.net/tags/r%C3%A9flexions

http://lehollandaisvolant.net/index.php?d=2013/01
http://lehollandaisvolant.net/2013/01

http://lehollandaisvolant.net/index.php?mode=links&id=20121023124938
http://lehollandaisvolant.net/links/20121023124938

Si j'ai oublié quelques correspondances, ajoutez-les à la suite. Le code source est disponible chez moi et cette version alpha mise en production sur mon blog. J'utilise Mercurial, vous pouvez donc voir le développement avancer.

À terme, Timo devrait intégrer la fonctionnalité dans ses développements (la branche principale) qui serait désactivée par défaut.

Julien et Nel : #

Pour ma part, j'ai laisser le choix pour mon script.

Soit on peut activer la réécriture ou alors la désactivé.

Après, ce n'est pas une réécriture avec des beaux titres, mais un truc du genre : article-1.php, article-2.php, etc .

Pour ma part c'est juste pour permettre le référencement dans google, mais on peut très bien sans passer ...

Hegurka : #

Si quelque part à un certain moment, ce genre de question (rewriting URL) apparaît comme nécessaire, OK. Mais si on n'en ressent strictement aucun besoin, c'est du débilisme profond. Est-ce que je mets des enjoliveurs avec un rayon plus petit que mes enjoliveurs actuels ? Aïe aïe aie !! Quel problème !
- Ouais, alors tu vois, euh, moi, j'ai toujours tenu à avoir des enjoliveurs archement classes si tu veux, je dirais...
Etc.
Je suis de ton avis, le Hollandais !! :)

Le lapin masqué : #

Pour un blog, "l'URL compacte" ou non, franchement, on s'en fout un peu, encore que... Je vais simplement prendre mon cas, qui est celui que je connais, fatalement, le mieux.

Certes, je fais partie des "utilisateurs très avancés" qui, paradoxalement, utilisent des "vieilles" technologies (parce qu'ils préfèrent avoir un moteur et le péter que d'avoir un boitier plastique moteur qu'ils ne peuvent pas bricoler) et tout ce genre de choses... Mais voici pourquoi je pense que les URL compactes sont utiles et aucunement "juste esthétiques".

Il est extrêmement fréquent, encore aujourd'hui, de trouver des liens "cliquez ici". Outre le désagrément causé aux surfeurs handicapés, c'est manque d'information sur le contenu du lien. En ce sens, surbriller le lien (ou passer la souris dessus) affiche la destination dudit lien et c'est là que l'URL compacte prend tout son sens :

- on sait sur quel site on va (chose pour laquelle je déteste les "raccourcisseurs d'URL")
- on sait de quoi va traiter la page (http://www.mydomain.ltd/this-is-a-page-about-elephants-reproduction)
- en règle générale, on sait de quand date l'article (pas gênant pour un domaine "canon" mais beaucoup plus pour une actualité)

En clair, d'un coup d'oeil, on peut déjà évaluer un certain nombre de choses.

Autre point : j'ai appris à mémoriser les URL intéressantes. Certes, c'est un réflexe qui date de l'époque où le transport de données sur un support physique coûtait vraiment de l'argent. Mais le fait est que j'ai acquis une certaine capacité à me rappeler des URLs qui me servent ou servent les autres...... si tant est que c'est une URL mémorisable.

Dernier point, mais celui-ci ne s'applique pas aux blogs, c'est que je RÊVE, dans mon métier, du jour où tous les fournisseurs auront une URL permettant d'accéder d'un coup à une référence. Parce que, soyons honnête, AUCUN d'entre eux n'a de moteur de recherche efficace (moteur de recherche mélangeant les articles, les news, les références produits, les commentaires, etc. ou même moteur de recherche carrément pas pertinent parce qu'avec un full text foireux) quand il ne passe pas carrément par Google pour ce faire.

Un site où tu entrerais directement la référence du produit (genre http://www.fournisseur.tld/keyboards/UA00-456) ça ferait gagner énormément de temps, au lieu de se coltiner des URLs de 15 km de long, qui embarquent en milieu de querystring une sessionid que du coup quand tu fous cette page en marktapage et que tu veux revenir dessus il te renvoie à cette putain de page d'accueil de merde en te disant "votre session a expiré" alors que tu t'étais même pas logué et que du coup tu dois repasser par leur putain-de-moteur-de-recherche-de-merde !!! Et ils sont TOUS comme ça. TOUS. EVERY. SINGLE. ONE.

Donc condamner les URLs compactes juste parce que tu n'en vois pas l'utilité pour ton blog (qui fournit déjà les infos nécessaires et que, franchement, taper 3 caractères de plus, c'est pas la mort, surtout quand il n'y a AUCUNE norme pour les URLs compactes), c'est un peu rapide je trouve.

Par contre, le jour où tu changes de technologie..... mais c'est une autre histoire que quelques expressions régulières peuvent très bien régler.

Le lapin masqué : #

Merde, on peut pas éditer son commentaire. Bon, vous aurez corrigé les mots manquants, les fautes d'accord et les erreurs de typo par vous même hein :p

alz : #

À la lecture de tout ça, il me vient une idée :
un "protocole" ou de simples balises meta, où dans une structure genre json on donnerait l'arborescence du site.
Pour que le navigateur affiche à coté de l'url une petite icône (un "+" ou une flèche), il n'y aurait plus qu'à cliquer dessus pour aller directement où on veut sur le site -> plus de menu à faire sur le site :p

Sinon je suis pour une url "belle", comme le dit Luc
- plus simple à retenir
- sépare la présentation du fonctionnement interne.

alz : #

Oui voilà, un sitemap qui s'intègre au navigateur..
..et à jour.. :p

Le Hollandais Volant : #

on peut mettre une balise meta avec rel=sitemap et une href/url/link vers le sitemap...

Cette balise pourrait être exploitée en JS ou par le navigateur lui-même.

jeux pistolet : #

J'espère que tu arriveras cette fois-ci à terminer tous les articles que tu avais laissé en suspend, j'ai déjà fait comme ça et c'est pas forcément facile de les reprendre ensuite...

Julien et Nel : #

Je me rappelle que quand je tenais un blog, je faisais une liste d'articles. Je finissais par détruire cette liste au bout d'un moment ou a supprimer des idées, car au final je n'avais plus envie d'écrire sur ça. Il y avait aussi des articles que je laissais en brouillon que je finissais par détruire, car soit je n'avais plus la motivation de les continuer ou alors je n'avais plus l'idée de ce que je voulais dire quand j'avais voulu écrire l'article. Pour le codage, c'est la même chose des fois ... je met des choses sur une liste ou je commence une fonction, puis je finis par abandonné ce que j'avais commencé.

J'ai une mauvaise tendance à remettre les choses au lendemain ...

Le Hollandais Volant : #

@Julien et Nel : tu procrastine trop ;-) . Bienvenue au club .o/

@jeux pistolet : oh en général ce sont des articles qui sont indépendant de la date (pas des actus), et je peux sans problèmes les reprendre, mais c'est surtout l'envie ou la motivation.

Si je ne publie pas ces vieux articles "en cachette", peut être qu'un jour je les devoilerais tel quels tous en même temps :-).

G-rom : #

Waaa bin mince alors c'est bien la première fois que je ne suis pas d'accord avec toi. Les "belles" URL ont pas mal d'utilités, malgré tous les a priori que tu as, et les commentaires ci dessus t'en cites pas mal.

Ensuite Whaaaaaaaat


Autre chose : utiliser l’URL rewriting nécessite d’avoir une liste de toutes les correspondances entre les URL courtes et les URL longues sur son serveur. Si y’en a 5, ça va. Si y’en a 5000, c’est déjà autre chose : ça ralentit tout l’ensemble et c’est bof pour la maintenance…

Alors là non, ou alors tu t'y prends très mal.

Et pour finir, tu as le droit de refuser une demande JUSTE parce que tu ne veux pas, tu n'es pas obligé de te justifier, surtout de cette manière ;)

Sbgodin : #

@G-rom : Je confirme :-) La correspondance est assurée via le serveur web. Le plus dur dans mes développements en cours c'est de bien coller à ce que Timo demande. Par exemple, le serveur doit bien ajouter "d=" ou "id=" pour faire la bonne requête.

Le Hollandais Volant : #

@Sbgodin : oui, mais pour mon site il n'y a pas que le blog, mais aussi des sous dossiers et des pages.
Il ne faudrait pas qu'une page réelle se retrouve avec un ?id= alors qu'il n'en faut pas et qu'il n'en a jamais fallu.
Faire ça en regex revient à faire une liste exhaustive des truc qu'il ne faut pas rediriger, et donc d'en arriver à une bonne grosse liste, que ce soient les url à réécrire ou celles qu'il ne faut pas réécrire.

D'où encore une fois, mon choix de la simplicité et de la logique : un article de blog est un cas particulier de la page index.php du blog, déterminé au moyen d'un paramètre sur l'url.

Sbgodin : #

Il y a effectivement une liste de réécriture, qui devrait faire à terme pas plus de cinq lignes. Elle devrait préciser uniquement ce qu'il y a à réécrire. Par défaut, tout ce qui n'est pas dans cette liste passe tel quel.

Ceci dit, sauf si j'ai mal prévu, l'accès via les urls classiques reste toujours possible. À la base, le travail consiste à faire que le blog génère des "jolies url" et faire en sorte que le serveur web les réécrive bien de sorte à ce que le code du blog les reçoive de façon conventionnelle.

Dans mes développements actels, la regexp de réécriture ne comporte qu'une ligne :
RewriteRule ^([0-9].*)$ /index.php?d=$1 [L]
Ce qui fait :


extérieurement http://XXXXXX/2012/12/19/16/55/08-titre
intérieurement http://XXXXXX/index.php?d=2012/12/19/16/55/08-titre


On peut aussi envisager http://XXXXXX/articles/2012/12/19/16/55/08-titre
au lieu de ça http://XXXXXX/2012/12/19/16/55/08-titre.

Minipipo1 : #

Tu t'en fous de l'apparence des URLs ?
Si on commence comme ça on peut aussi, sous prétexte que c'est plus rapide et plus facile à faire, ne pas acheter de nom de domaine et utiliser une adresse IP à la place...

Je suis d'avis que l'URL doit être le plus beau possible pour que l'utilisateur, s'il le souhaite, puisse l'utiliser directement.
Tu ne souhaites pas de belles URLs ? C'est bien ce que tu as fait en détournant le problème en ne mettant qu'un paramètre GET "d" sur Blogotext.
Vraiment je comprends pas les coups de gueule lancés pour pas grand chose des fois, là il te suffirait avec une toute petite regex de rien du tout d'une ligne dans ton .htaccess pour enlever ce "?d=" puisque tu as déjà prévu tous les traitement en aval avec PHP je présume.

Ce serait juste un fonctionnalité toute bête et que tu peux développer en moins de 10 minutes et que beaucoup de monde utilisera je pense ;)

Julien et Nel : #

Pour information aussi, il existe d'autres type de serveurs qui n'utilisent pas apache.

Donc dans certains cas, il faut penser à une alternative à le htaccess (En gros permettre d'avoir les urls simples).

Le Hollandais Volant : #

@Minipipo1 : si tu veux mon avis, vu la façon dont je travaille moi, ça me gênerais aps d’utiliser les IP et me passer des DNS. Ça sera plus rapide, et les USA n’auraient alors plus le contrôle les serveurs racines du Web.


pour enlever ce "?d=" puisque tu as déjà prévu tous les traitement en aval avec PHP je présume.


Justement, je ne veux pas le retirer : il est là et il sert à quelque chose. Je l’ai ajouté parce que j’en avais justement besoin !


Ce serait juste un fonctionnalité toute bête et que tu peux développer en moins de 10 minutes et que beaucoup de monde utilisera je pense ;)



Le htacess peut transformer une URL longue sur une courte (en utilisant des regex et en masquant des trucs. Mais pour faire l’inverse, il faut PHP avec un dictionnaire "url-longue/url-courte" quelque part…

Exemple :
Passer de
http://XXXXXX/?d=2012/12/19/16/55/08-titre
à
http://XXXXXX/titre
Est très simple (une ligne de .htaccess).

Mais une fois que l’utilisateur partage l’URL « http://XXXXXX/titre », comment le serveur il fait pour donner à PHP le paramètre qui lui manque, à savoir l’id de l’article ? (à moins que PHP utilise un dictionnaire).
Et c’est là dedans que j’ai pas trop envie de me lancer, vu que ça ne fait rendre que compliqué quelque chose dont le besoin est pratiquement nul.


puisque tu as déjà prévu tous les traitement en aval avec PHP je présume.



Mon traitement en aval se résumé (en gros) à ça : $id = (isset($_GET["d"])) ? implode(explode(substr($_GET['d'], 0, 19), '/'), '') : NULL;

@Julien et Nel : justement, si on met pas de ré-écritures alacon partout, ça marchera sur tous les serveurs, du moment que PHP ait accès aux paramètres de l’URL.

Sbgodin : #

@Le Hollandais Volant : [au sujet de &id=] Il faut le garder. En interne.


Le htacess peut transformer une URL longue sur une courte (en utilisant des regex et en masquant des trucs. Mais pour faire l’inverse, il faut PHP avec un dictionnaire "url-longue/url-courte" quelque part…


C'est le contraire. La requête en entrée est du genre site/url/toute/belle/ et est réécrite avant que le Php ait la main dessus. Le php qui intercepte les paramètre n'y voit que du feu. Par contre, le php qui construit les liens des pages lui doit préparer de belles url.


Mais une fois que l’utilisateur partage l’URL « http://XXXXXX/titre », comment le serveur il fait pour donner à PHP le paramètre qui lui manque, à savoir l’id de l’article ? (à moins que PHP utilise un dictionnaire).


La règle RewriteRule ^([0-9].*)$ /index.php?d=$1 [L] le fait. Il passe d'une url toute belle à /index.php?d⁼XXXXX. Le XXXX étant ce qui a été capturé par la parenthèse de la regexp.

Dans ma proposition de développement,via mercurial l'essentiel des modifications à faire est là : faire que tes liens deviennent tout beau côté navigateur. Côté serveur, rien n'est modifié. C'est moche et c'est de l'apha. L'autre modification est juste la regexp. L'utilisation de la réécriture est tout à fait optionnelle et ne devrait pas infléchir sur les développements futurs.

Le Hollandais Volant : #

@Sbgodin : justement, comment tu la réécrit, ton URL belle et courte ? Si y'a pas l'id, comment PHP peut la trouver ?

Sbgodin : #

@Le Hollandais Volant : Je vais prendre comme exemple mon blog où la version alpha est déjà en production. Voici une adresse typique : http://blog.sbgodin.fr/2011/10/09/21/32/21-permutation-sans-variable-intermediaire
Lorsque le serveur web la voit passer, les règles de réécritures s'appliquent. La règle en question est, actuellement en production, la suivante : RewriteRule ^([0-9].*)$ /index.php?d=$1 [L]
L'adresse http://blog.sbgodin.fr/2011/10/09/21/32/21-permutation-sans-variable-intermediaire devient http://blog.sbgodin.fr/index.php?id=2011/10/09/21/32/21-permutation-sans-variable-intermediaire. Cela se fait au niveau du serveur, de façon invisible pour le client, et avant que le php ne reçoive la requête.

Le php voit donc l'url comme s'il n'y avait pas de réécriture, et le paramètre id est encore présent. Les parenthèses capturantes de la regexp permettre de donner au paramètre id la bonne valeur.

Évidemment, cette regexp est à revoir. Mais c'est l'idée principale. Donc, à la base, il ne faut faire que ceci :
* faire la réécriture d'url afin que le script php voit la bonne url en entrée
* les scripts php produisent les belles urls

Julien et Nel : #

@Sbgodin :

Sgbodin, il faut je pense déjà faire son script sur des urls qui ne nécessitent pas apache. Les belles urls, c'est super ... mais ça ne marche pas partout. Il suffit qu'il y est pas la réécriture activée ou que le serveur n'utilise pas apache pour se retrouver avec des urls belles, mais toutefois inutilisables. Certains aussi oublient de copier le htaccess, après ils ont des urls qui ne marchent pas et ils ne savent souvent pas comment utilisé les urls simples.

Pour être honnête la majorité des personnes s’en-foutent de voir comment l'url est constitué, ils regardent surtout le résumé et le titre. Souvent les personnes cliquent directement sur le titre du lien que ça soit dans des trucs de liens (shaarli ou linx) ou des moteurs de recherches, ils ne regardent que rarement le lien qui est affiché dans la barre (ils consultent, lisent et ferment la fenêtre). Dans le pire des cas, la personne peut toujours proposé un titre à son lien au lieu de le laisser en brut (vous savez le truc qu'on met entre le <a> et le </a> ...).

Le Hollandais Volant : #

@Sbgodin : je vois bien ce que ton script fait, mais quid si tu veux maintenant virer tous les chiffres et ne mettre que site.com/titre-bla-bla ? Une ligne de code apache ne suffira pas.

Sbgodin : #

@Le Hollandais Volant : Tu as raison. Le serveur web ne connaît pas la correspondance entre les noms d'articles et leur identifiant dans Blogotext. Mais c'est en fait une mauvaise idée d'utiliser seulement le titre à cause des risques de collision.
Ici la réécriture est simple parce ce n'est qu'un copier/coller de l'id. Sinon, il faudrait que le php aille rechercher dans la base le titre en lieu et place de l'id. C'est possible aussi, et il n'y a aucune table de correspondance à maintenir puisque le titre jouerait le rôle d'identifiant. Mais ça impacte bien fortement tes développements...

Je suis d'accord avec le fait que la réécriture d'url dépend du serveur web. Mais c'est une affaire de portage et de documentation. Apache, Ngix voire IIS et c'est à peu près tout. Donc, il me paraît évident que la réécriture doit être absolument facultative et doit impacter le moins possible les développements.

Le Hollandais Volant : #

@Sbgodin :


C'est possible aussi, et il n'y a aucune table de correspondance à maintenir puisque le titre jouerait le rôle d'identifiant.


Justement, la table de correspondance serait directement dans la BDD.
Et ça n’autoriserait ni modification du titre, ni encodage des caractères…

Pourtant, certains comme Wordpress le font comme ça.


Mais ça impacte bien fortement tes développements...


C’est surtout que ça serait se faire chier pour rien…

Sbgodin : #

C'est bien pour ça que garder l'id tel que tu le fais, c'est bien. Le travail est minimal. Mes travaux actuels sont de la version alpha mais ça illustre bien le principe. De la regexp côté serveur web, et une production d'url jolie du côté php. Cela interfèrera peu avec tes développements.

financiers : #

C'est vrai que les url courtes c'est mieux pour le référencement, mais après tout dépend de ce qu'on veut faire avec son site, si il n'y a aucun enjeu financier, alors c'est vraiment pas important.

Gee : #

Ça dépend des usages, j'imagine... Personnellement j'ai utilisé des URL courtes pour le Geektionnerd parce que ça me permet d'avoir accès à un article juste en tapant le nom. Exemple : je recherche l'article sur la pluie, je sais que c'est http://geektionnerd.net/pluie
Mais j'avoue que c'est surtout dû au fait que mon blog est construit comme un dictionnaire et que c'est donc "logique" d'avoir accès aux entrées comme ça. Si ça se trouve, je suis le seul à me servir de ce truc :p

petitkoalak : #

Personnellement j'utilise les belles urls comme nom pour mes caches également. Ça me permet de les identifier plus facilement et d'avoir des noms de fichiers clairs et propre. Ensuite ça fait plus professionnel, plus classe et les clients aiment ça (témoignages et non expérience) etc
Et même pour moi ça me rend la navigation bien plus agréable et je suis content de mes belles urls après chacun fait ce qui lui plait et basta

Sbgodin : #

@Julien et Nel : Je planche sur la question pour un besoin personnel. Utilisant Blogotext personnellement, je voudrais qu'il fasse la séparation entre le back-office et le front-office. Par exemple, on utilise "id", "d" et autres comme variables en interne. Mais on les utilise aussi comme références à l'extérieur. C'est ainsi que fonctionne le web par défaut, mais ça entraîne un couplage entre l'apparence extérieure et les besoins internes. En programmation, c'est un peu comme si les paramètres formels et effectifs devaient être identiques.

Par exemple, si Timo décide d'utiliser en interne "date" au lieu de "d" ça invalidera tous les liens. Pour ce cas-là en particulier, on pourra toujours faire la modification à la volée avec de... la réécriture d'url !

Pour cela, j'aimerais bien que les urls ne contiennent que ce qui sert à identifier la ressource à accéder, laissant au code sous-jacent le soin de l'interpréter. Par exemple : ''http://lehollandaisvolant.net/2013/01/16/14/09/11'' sera compris aujourd'hui comme ''http://lehollandaisvolant.net/?d=2013/01/16/14/09/11''. Mais demain, ça pourrait être ''http://lehollandaisvolant.net/?year&month=01&day=16&hour=14&minute=09&second=11''. Avec la réécriture d'url, le changement interne n'est plus visible et on peut coder tranquille.

sil : #

Je suis a 200% d'accord avec toi. Autre argument de poids, c'est la galère de reconfigurer les htaccess quand on change d’hébergeur si la configuration d'Apache a le malheur d’être un chouia différente.

Roultabie : #

Ou encore plus simple, un .htaccess avec
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

Tout est redirigé vers index.php, chez moi, c'est une classe urlRewrite qui traite tout avec les regex. Ainsi, je peux ajouter autant de type de liens que je veux.

Pour moi, l'url rewriting c'est le petit détail du webmaster (une petite signature quoi ;) ) genre chez moi :
http://mydomain.tld/articles/categorie/mon-article.html
ou articles est tout ce que tu veux (liens, pages ...)

Roultabie : #

EDIT: et grâce à cette règle, on évite le problème que tu cite plus haut :
Si un fichier ou un répertoire existe, il ne renvoie rien vers index.php mais pointe bien vers la ressource demandée.

Le meilleur des deux mondes

Julien et Nel : #

Bon rien avoir avec le débat, mais pour les problèmes "de ? ; , :", des lettres majuscules ou de "é, è à, Â, Ô" ..., voilà un petit morceau de code que j'ai adapté et ajouté sur la règle des belles urls. Ca évite dans le cas qu'on voudrait faire une belle url que celle-ci foire si il y a une majuscule, de la ponctuation ou des accents.

$news['titre'] = preg_replace( "`&([a-z])(acute|uml|circ|grave|ring|cedil|slash|tilde|caron|lig);`i","\\1", $news['titre'] );
$news['titre'] = preg_replace("`\[.*\]`U","",$news['titre']);
$news['titre'] = preg_replace('`&(amp;)?#?[a-z0-9]+;`i','-',$news['titre']);
$news['titre'] = preg_replace( array("`[^a-z0-9]`i","`[-]+`") , "-", $news['titre']);
$news['titre'] = ( $news['titre'] == "" ) ? $type : strtolower(trim($news['titre'], '-'));
$news['titre'] = htmlentities($news['titre'], ENT_COMPAT, 'utf8');

Je me suis inspiré de la fonction " format_url" de phpBB qui fait très bien son boulot.

tsyr : #

@bajazet :
Je vais aller à l'encontre de l'avis de Guillaume, et te recommander plutôt 2012/01/01
Pour rejoindre les écrits de Quentin, ça sera bien plus pratique en supprimant le jour, pour accéder aux articles du mois, ou aux articles de l'année, on simule une arborescence chronologique.

LeDave : #

@seb :
Je dirais même plus: Le nombre de gens qui confondent le champs URL avec le champs de recherche sur la page Google et maintenant, les nouveaux browser qui balancent automatiquement le contenu du champs d'URL vers... Google en cas de 404... Madame Michu si elle n'en a rien à battre, elle n'en pige pas une louche.

thib : #

@LeDave : Y'en a même (Firefox Mobile par exemple) qui poussent le vice jusqu'à masquer l'url, en la remplaçant par le title. Il faut cliquer sur le title pour afficher l'url... Perso ça me hérisse le poil de ne pas savoir du premier coup d'oeil sur quel domaine se trouve l'info que je lis. Je ne parle même pas de la sécurité, rien n'empèche de coller "https://paypal.com" en title d'une page...

Bon pour revenir au sujet, tant que le titre de l'article apparaît dans l'url, je m'en cogne qu'il y ait d'autres infos.

Guenhwyvar : #

@Roultabie : Je comprends pas bien ton système… Ta classe fonctionne comment ? Elle analyse $_SERVER['QUERY_STRING'] (ou autre du même genre) pour savoir quel contenu servir ?

Roultabie : #

@Guenhwyvar : L'url rewrite m'envoie une chaine de caractères genre : /articles/catégorie1/mon-article.html ou /articles/page/2

La classe les parse et crée les variables nécessaires : $t = articles $c = categorie1 $n = mon-article ou $t = articles $p = 2

Les commentaires sont fermés pour cet article