Community « Le forum « Nouvelles fonctions «
7.4 : Vers la normalisation des raccourcis rewrités
Pinelli, Thierry -- on May 21 2007, from Nice, DrapYACS team - SEO
VDP-Digital : service référencement / SEO
Presque un mois est passé depuis la sortie de la version 7.4 de Yacs. Tout ou presque a été optimisé pour offrir aux utilisateurs de Yacs un site digne d'un prestataire de service SEO...
Mais il reste encore quelques optimisations qui resiste, encore et toujours, à l'envahisseur Yacsien !
Objet : Raccourci balises YACS incorrect :
Le raccourci
Même constat pour le raccourci GO qui renvoit toujours vers l'ancienne écriture.
En l'état actuel de l'organisation de Yacs en matière d'optimisation SEO, il est impératif que tous les liens renvoient vers le même url.
Présence connue : Balise "article", Balise "go"
Solution : Aligner le rendu de cette balise
Ajout : Objet : Raccourci balises YACS incorrect :
Le raccourci [*toc] renvoyé par les raccourci yacs [*title] et [*subtitle] pourraient renvoyer vers des raccourci interne (ancre) portant le nom du title et non un numéro. Toujours dans l'idée qu'un lien, quelque qu'il fut, doit comporter une maximum d'indication textuelle... Difficulté : Remplacer les espaces par des tirets, mais je crois que gnapz est déjà sur le coup Solution : Indiquer le titre et non le numéro.
Objet : Lien vers la raçine du site
Les retours vers la page d'accueil en "index.php" sont à proscrire. Pour google, il existe deux pages : www.333monsite.fr/ et www.333monsite.fr/index.php avec un contenu identique.
C'est ce que l'on appel du "duplicate content". Ces pages peuvent être potentiellement pénalisées par les algorithmes des moteurs de recherches. La cause : Du contenu identique dupliqué sur plusieurs url.
Présence connue : Header (raccourci image), Menu, tabs
Solution : supprimer les retours vers index.php et toujours renvoyer vers la raçine.
Dans l'immédiat seul l'url de la page d'accueil est concerné. Mais à terme, c'est toutes les relations aux index.php (sections, articles, etc...) qui sont à proscrire pour la même raison.
Objet : Layout à actualiser
L'ensemble des Layouts ne fonctionnent toujours pas correctement. En n'indiquant pas le numéro de section, il y a des risques de "duplicate content"
Présence connue : Home_layout
Solution : Aligné le rendu des liens des home_layout sur ceux de article_layout qui fonctionnent parfaitement.
Ajout 2: Objet : Liens de renvoi des étiquettes incorrectes dans les articles.
Dans un article qui à fait l'objet d'un "étiquetage" les liens qui renvoient, en haut de la page de l'article, aux étiquettes (catégories) correspondant ne contiennent pas le numéro de section (format incorrect)
Je pense que cela est modifiable dans les layouts ?
Présence connue : étiquettes de sections, catégories. Solution : Indiquer le numéro de section.
Objet : URL rewriting dans les catégories
L'ensemble des liens des catégories et sous catégories ne sont toujours pas rewrité.
Présence connue : Catégories, sitemap
Solution : Rewriter les liens et retour de liens des catégories selon le format standard :
../45/nom_categorie
A coté de ces quelques points encore en cours d'amélioration, Yacs fait un véritable "bon" à chaque nouvelle version.
La carte sitemap, outil incontournable pour le référencement, en particulier avec Google, est quasiment parfaite, les liens contextuels sont tous rewrités, l'ensemble des liens présents dans une propulsion Yacs fonctionnent tous grâce à un renommage d'une simplicité enfantine (il suffit de donner un surnom à une page pour que celle ci soit AUTOMATIQUEMENT rewrité, si votre configuration serveur le permet.).
Vous ajoutez à cela des balises "title" qui s'adaptent au titre de vos pages, une Gestion des erreurs 404 et une amélioration systématique au cous des versions et vous obtenez une solution qui n'a rien à envier aux plus grandes !
Objet : Raccourci balises YACS incorrect :
Le raccourci
[/article=nom de l'article] renvoi vers l'url sans le numéro de section : ../../nomdusite/nom-de-atricle au lieu de ../../nomdusite/44/nom-de-atricle.Même constat pour le raccourci GO qui renvoit toujours vers l'ancienne écriture.
En l'état actuel de l'organisation de Yacs en matière d'optimisation SEO, il est impératif que tous les liens renvoient vers le même url.
Présence connue : Balise "article", Balise "go"
Solution : Aligner le rendu de cette balise
- - - - - - - - - - - - - - - - - - - -
Ajout : Objet : Raccourci balises YACS incorrect :
Le raccourci [*toc] renvoyé par les raccourci yacs [*title] et [*subtitle] pourraient renvoyer vers des raccourci interne (ancre) portant le nom du title et non un numéro. Toujours dans l'idée qu'un lien, quelque qu'il fut, doit comporter une maximum d'indication textuelle... Difficulté : Remplacer les espaces par des tirets, mais je crois que gnapz est déjà sur le coup Solution : Indiquer le titre et non le numéro.
Objet : Lien vers la raçine du site
Les retours vers la page d'accueil en "index.php" sont à proscrire. Pour google, il existe deux pages : www.333monsite.fr/ et www.333monsite.fr/index.php avec un contenu identique.
C'est ce que l'on appel du "duplicate content". Ces pages peuvent être potentiellement pénalisées par les algorithmes des moteurs de recherches. La cause : Du contenu identique dupliqué sur plusieurs url.
Présence connue : Header (raccourci image), Menu, tabs
Solution : supprimer les retours vers index.php et toujours renvoyer vers la raçine.
Dans l'immédiat seul l'url de la page d'accueil est concerné. Mais à terme, c'est toutes les relations aux index.php (sections, articles, etc...) qui sont à proscrire pour la même raison.
Objet : Layout à actualiser
L'ensemble des Layouts ne fonctionnent toujours pas correctement. En n'indiquant pas le numéro de section, il y a des risques de "duplicate content"
Présence connue : Home_layout
Solution : Aligné le rendu des liens des home_layout sur ceux de article_layout qui fonctionnent parfaitement.
- - - - - - - - - - - - - - - - - - - - - - - - -
Ajout 2: Objet : Liens de renvoi des étiquettes incorrectes dans les articles.
Dans un article qui à fait l'objet d'un "étiquetage" les liens qui renvoient, en haut de la page de l'article, aux étiquettes (catégories) correspondant ne contiennent pas le numéro de section (format incorrect)
Je pense que cela est modifiable dans les layouts ?
Présence connue : étiquettes de sections, catégories. Solution : Indiquer le numéro de section.
Objet : URL rewriting dans les catégories
L'ensemble des liens des catégories et sous catégories ne sont toujours pas rewrité.
Présence connue : Catégories, sitemap
Solution : Rewriter les liens et retour de liens des catégories selon le format standard :
../45/nom_categorie
A coté de ces quelques points encore en cours d'amélioration, Yacs fait un véritable "bon" à chaque nouvelle version.
La carte sitemap, outil incontournable pour le référencement, en particulier avec Google, est quasiment parfaite, les liens contextuels sont tous rewrités, l'ensemble des liens présents dans une propulsion Yacs fonctionnent tous grâce à un renommage d'une simplicité enfantine (il suffit de donner un surnom à une page pour que celle ci soit AUTOMATIQUEMENT rewrité, si votre configuration serveur le permet.).
Vous ajoutez à cela des balises "title" qui s'adaptent au titre de vos pages, une Gestion des erreurs 404 et une amélioration systématique au cous des versions et vous obtenez une solution qui n'a rien à envier aux plus grandes !
Comments
Un point de détail, il faut penser aux confusions sur une base url/surnom car au bout on a quoi, une section, une catégorie, un article, un fichier, un lien, une image, etc ?
Articles, fichiers, images et liens sont du contenu alors j'obterais pour 3 solutions (à terme):
- un rewriting url/section/sous-section/contenu
- Un module de recherche de doublons en javascript (auto-completion) qui interdirait la saisie d'un surnom déjà utilisé.
- Rendre le champ surnom aussi visible et important que le titre (car ce sera le cas).
Je suis sur un bout de code pour générer un surnom codifié à partir du titre ... mais je bute sur des pb stupides qui n'ont rien à voir avec le boulot: impossible de récupérer le titre et le nick_name d'un article dans articles/edit.php !!! Gros nul quand même ! Pour ceux qui y arrivent, je pars sur le principe suivant:
- utilisation de preg_replace
- suppression des codes yacs et autres balises html
- suppression des caractères de contrôle php (:control:)
- suppression de la ponctuation (:punct:)
- remplacement des espaces par des soulignements (_)
- remplacement des caractères accentués par des universels.
C'est pas compliqué, quelques boucles d'analyses et remplacement des caractères ... mais j'arrive pas à récupérer ces 2 champs titre et nick_name !!! Dingue, ça !
GnapZ :
url/section/sous-section/contenu
Cela pourrait-être la seconde étape de ce grand chantier du rewriting.
En espérant qu'à terme, plus aucun numéro ne sera affiché, mais seulement les surnoms des section/categorie/page etc...
View.php devra disparaitre lui aussi pour que tout soir parfait.
Ca me laisse le temps de poster pas mal de message à chaque nouvelle version d'ici là
Un module de recherche de doublons en javascript (auto-completion) qui interdirait la saisie d'un surnom déjà utilisé
C'est l'un des avantages de la numérotation. Elle permet d'éviter d'arriver à des doublons trops facilement. Mais c'est vrai que ce que tu proposes est une excellente idée.
Rendre le champ surnom aussi visible et important que le titre (car ce sera le cas)
Si tu arrives à finaliser ton script pour la reprise du titre dans l'url, ce ne sera même plus utile
Bien que le surnom puisse permettre de fournir une url différente du titre. Pratique pour éviter les apostrophes et autres caractères spéciaux.
En attendant, c'est vrai que l'on pourrait rendre le champs "surnom" beaucoup plus visible lors de la création d'une page... Ca serait un premier pas intéressant.
Très très intéressant cette discussion.
Juste une remarque en passant :
" Un module de recherche de doublons en javascript (auto-completion) qui interdirait la saisie d'un surnom déjà utilisé
C'est l'un des avantages de la numérotation. Elle permet d'éviter d'arriver à des doublons trops facilement. Mais c'est vrai que ce que tu proposes est une excellente idée. "
Je trouve l'idée excellente, c'est aussi un point que nous avons abordé pour un de nos projets. Attention toutefois : il me semble important de pouvoir autoriser des doublons de surnom, et en particulier pour les langues : une même page en anglais, français et italien par exemple devrait pouvoir avoir le même surnom et renvoyer après, selon les préférences du visiteur, vers la page localisée de son choix.
En dehors de cela, c'est vrai qu'un "catalogue dynamique" des termes déjà utilisés serait un vrai plus. Et j'irai même plus loin en adoptant cette fonctionnalité pour la création de catégories par mots clés sur le même principe, ou encore pour le choix des mots-clés à utiliser pour les pages et sections.
-----
Agnès
Il n'y a pas de problèmes, que des solutions.
Pour Agnès : A voir La valse des étiquettes [7.9] Je ne sais pas si c'est l'idée que tu avançais au sujet des catégories, mais qui sais ? :p
Un petit ajout :
Objet : Raccourci balises YACS incorrect :
Le raccourci [*toc] renvoyé par les raccourci yacs [*title] et [*subtitle] pourraient renvoyer vers des raccourci interne (ancre) portant le nom du title et non un numéro. Toujours dans l'idée qu'un lien, quelque qu'il fut, doit comporter une maximum d'indication textuelle... Difficulté : Remplacer les espaces par des tirets, mais je crois que gnapz est déjà sur le coup :p
Autre petit ajout, avant l'arrivé de la 7.5 !
Objet: Liens de renvoi des étiquettes incorrectes dans les articles.
Dans un article qui à fait l'objet d'un "étiquetage" les liens qui renvoient, en haut de la page de l'article, aux étiquettes (catégories) correspondant ne contiennent pas le numéro de section (format incorrect)
Je pense que cela est modifiable dans les layouts ?
Présence connue : étiquette de section, catégories Solution : Indiquer le numéro de section.
Je suis toujours sur ce script (délaissé quelques jours) pour les nick_names.
Pour l'url-rewriting final, ne serait-il pas mieux d'intégrer la langue en premier comme on le voit dans tous les grands sites internationnaux ?
"htttp://www.yetanoz.com/fr/section/article.php"
Bien sûr, je parle de l'idée finale ...
GnapZ :
Oui, ça serait une excellente idée.
Mais comme tu le dit, il va y avoir quelques étapes avant d'arrivé à cela.
Pour rappel on est parti de :
-http://www.cecicela.yacs/section/view.php/33
puis
-http://www.cecicela.yacs/section/view.php/article
Actuellement on est sur :
-http://www.cecicela.yacs/section/view.php/33/article
Et par étape ont devrait arriver progressivement a :
-http://www.cecicela.yacs/section/33/article
(suppression du view.php)
-http://www.cecicela.yacs/section/nom_section/article
(remplacement du numéro par le nom de la section/catégorie parente) - QUI RESTE A DÉBATTRE !
-http://www.cecicela.yacs/nom_section/article
(suppression du paramètre section (ou article, ou comment)
Pour atteindre l'optimisation optimale :
-http://www.cecicela.yacs/fr/nom_section/article
(ajout du paramètre de langue)
Le débat reste ouvert sur l'objectif final à atteindre et le risque de doublonnage des articles/sections... De toute façon, il est plus sage de procéder par touches successives afin de tester l'ensemble des urls et vérifier le bénéfice des évolutions.
Je ne sais pas si je vais dire une bêtise mais vu l'activité de l'internationalisation actuelle, je pencherais pour placer la langue dans l'url en priorité.
On pourrait se baser sur la langue de l'article final (visé par l'url) suivant le choix effectué dans la liste en bas d'article.
Je pense en effet qu'en évolution vers le professionalisme tel que nous sommes, c'est un point primordial. De plus, cela implique sûrement une restructuration de l'arborescence des sections et donc du site.
Pour le reste, je pense qu'il vaut mieux déjà vérifier que toutes les url respectent la même structure, ce qui n'est pas encore le cas je crois.
C'est juste mon avis ... qu'en pensez-vous tout le monde ?
GnapZ: Je réagis vite, sans avoir vu tout le fil de discussion, juste pour témoigner que la norme HTTP, comme leur implémentation dans Apache, privilégient la négociation du contenu plutôt que leur détermination dans une adresse web. En clair, la tendance normative serait plutôt d'éviter les 'fr' et autres gracieusetés dans les URLs... Je vous invite à regarder ce qui a été fait pour Apache 1.3 VF, par exemple
When I last did some SEO work (a few years ago), search engines liked article/view.php/342 as much as /view.php/234/MyArticle ...
Has this changed ?
Also, a problem I know of with using the title - nick name in the url is, if the title changes, this reduces the URL's effectiveness.
Google might be better at handling this now ?
Cheers, Nick
-----
Nick
NickR :
view.php/234/MyArticle is better because a key word is inside. But view.php/234 is better than view.php/?id=234
For a second question, i don't understand
Why nick name reduce URL's effectiveness ? Nick name is a another key word inside a title of the page (meta balise title on html header) and for url !
The law is : One Key word is better than a other parametre and two key word is better than one
If google love that ? Of course !
Et je demande au moins un mot en français maintenant. Sinon je ne répond plus !

J'ai joué ce soir avec le fichier
.htaccess de mon WAMP server (très belle bête, vraiment, ce serveur intégré) et le résultat, c'est que YACS supportera aussi les belles URLS dès la prochaine version. Héhéhé...If google indexes with nickname "feature_factoooory" url -> "sections/view.php/185/feature_factoooory" (notice bad spelling), but then you correct it later "feature_factory" url "sections/view.php/185/feature_factoooory" , say a week later, google will pick this up as a new link.
I am not sure how the code in YACS works, but will google point to a dead link until it reindexes ?
Either we get 2 different url pointing to the same content (bad), or 1 good link and a 404 (worse).
This will effect ranking of your site until google removes obsolete indexes of your site.
What would help here is that we use a permanent redirect 301 if the nickname is invalid (but article/section/comment id is still correct) and make sure we avoid a 404 if JUST the nickname is incorrect.
:)
-----
Nick
NickR : You are right but imagine nicknames as ID. Each article has an id and you can change the title as you want but not the id. The idea is to lock the nickname when the field is filled once.
If you think that the nickname becomes not right with the content, you have to make a new article (or duplicate it to have a blank field for nickname).
Usually when you create an article and change the title, it is just to beautify but the content is still the same so the nickname is still good.
If think that my first idea to make an automatic nickname with the title content is not a good idea because of your good comment.
But we should continue to think about a javascript completion list because that will help a lot.
With the comment of Bernard about apache, i understand now that it is very important to permit different articles with the same nickname because of the localization.
Imaginons que les surnoms soient considérés comme les ID. C'est à dire que qu'un surnom devient verrouillé à l'article dès lors que ce champ est renseigné. Généralement nous modifions le titre d'un article pour l'embellir ou pour qu'il corresponde mieux au contenu mais cela ne change pas le contenu et le surnom est alors toujours valable.
Si le contenu ne lui correspond plus, alors il faut créer un nouvel article pour lui attribuer un nouveau surnom ce qui est déjà plus rare et donc éviterait au maximum les modifications d'url pour les moteurs de recherche.
D'après le commentaire de Bernard sur apache ci-dessus, il est effectivement important d'autoriser les doublons de surnoms à cause de la localisation. Les articles sont reconnus en fonction de leur surnom mais aussi de la langue associée.
Mes idées précédentes ne sont donc pas applicables mais la liste d'auto-complétion en javascript pourrait demeurer utile.
Je viens juste de voir le lien de Bernard sur l'utilisation des .htaccess: tout simplement génial.
Non seulement ça évite une énorme retouche des lins internes à Yacs (bien qu'il faille adapter tout ça quand même, bravo pour le boulot), mais ça apporte surtout une grande souplesse et un grand bon en avant sur l'url-rewriting !
NickR: In the implementation I am working on YACS only extracts the provided id and does not care about following text. Therefore, you can change the nickname at any time, and YACS will always serve the right page to Google. The trick is, as you have understood, in page ids used as label prefixes...
Gnapz, a suggested nickname would be a good feature, we could check for duplicates and possibly even spellcheck ?!? - javascript - I can see ajax being ideal for this, but I was thinking maybe a popup window (or iframe) to load in the suggestions would be a simpler method.
Bernard, only issue is that google will have multiple entries pointing to the same file (similar issue with index.php) - but with the ideas Gnapz and I have put above, we should be able to minimize the risk (and unlike index.php which is there all the time, chances of different nicknames pointing to the same article will be rare).
-----
Nick
Pour ceux qui auraient loupé cette information intéressante sur le futur yacs 7.6 : url rewriting
NickR: I have spent a lot of time in version 7.6 to ensure consistent usage of rewritten URL in YACS. Of course, it is likely that this effort will span several releases of the software. The goal, as explained by ThierryP, is to have only one reference for any page managed by YACS. Nobody is able to guarantee this ideal target. But at least, we can tend to it, as much as possible...
Je cherche depuis plusieurs jours à me documenter le mieux possible sur la meilleurs url imaginable tout en respectant l'architecture proposé par yacs.
Celle qui devrait être disponible dès la version 7.6 de yacs est donc celle-ci :
sections/456-nom_de_ma_page.htmlJe vais me permettre à quelques commentaires, entre convictions personnelles et constations professionnelles :
Tout ce qui est situé après le slash (/) est potentiellement considéré comme un mot unique par les moteurs de recherche (en théorie, car les séparateurs permettent de séparer les différents termes).
De ce point de vue la, joindre le numéro d'article au surnom n'est pas indispensable à priori. (surtout si a terme et comme je l'espère, le nom de la section finira par remplacer son numéro... pour un gain en terme de pertinence très appréciable)
Actuellement, Yacs a une architecture de liens sous la forme de
sections/456/nom-de-ma-page c'est déjà, si l'on excepte le numéro de section, une url presque parfaite.Si on part du principe que pour aller d'un point A vers un point B, la ligne droite est toujours le moyen le plus court (et plus rapide), je m'interroge sur l'intérêt d'indiquer l'extension .html pour terminer l'url.
Bien que personnellement je ne crois pas à l'intérêt de ce genre d'extension en fin de lien, force est de constater que c'est un paramètre repris par la quasi totalité des grands SEO : Notamment Brioude Internet et bien d'autres. (la seul différence notable étant l'utilisation du .php, .htm, ou .html)
Sur ce point là les faits semblent aller à l'encontre de mon intuition personnel.
Je reviens sur ce qui serait, à mon sens, l'écriture parfaite : [code]sections/nom-de-section/nom-de-page(/code]
A savoir deux séparateurs slash qui ont leur utilité et qui sont utilisés ici à leur juste valeur (séparer des sections bien définis, ainsi que le font les grandes enseignes SEO) pareillement, l'utilisation de tirets, plus lisible et plus communément acceptés que les autres séparateurs possibles (l'underscore, mais aussi la virgule, le signe plus, etc...) est à préféré (avec cependant un risque d'association de certains mots entre eux.
Tout cela mérite peut être une étude plus approfondie. Mais le point le plus important de tous :
S'en tenir à un format est ne plus en changer
A force de modifier l'architecture des urls, l'ensemble des sites fonctionnant sous yacs vont être pénalisés pour leur référencement.C'est bien pour cela que la stratégie de re-écriture des liens doit être réfléchie, clair et suivre un processus d'amélioration cohérent...
Bernard :
" Comme tu l'expliquais dans ton poste, je pense qu'il faut modifier l'architecture d'URL rewriting étape par étape. La version 7.6 marque un certain aboutissement, grâce à tes conseils, dans la logique d'intégrer les surnoms dans les adresses. Nous avons considérablement renforcé l'usage de .htaccess, et changé et optimisé des centaines de lignes de code, pour arriver à ce résultat. A ce stade, l'objectif immédiat est sans doute de déployer cette technologie, et de vérifier qu'elle s'adapte bien aux serveurs qui exploitent YACS.
A dire vrai, changer les adresses des articles pour y refléter la structure arborescente des sections n'est, à mes yeux, pas aussi évident qu'il y parait, tant sur le plan fonctionnel (quel impact sur les moteurs de recherche ?) que sur le plan technique (des requêtes en plus dans la base de données).
Il nous faut donc continuer d'optimiser la génération et l'usage d'adresses simplifiées sur la base de YACS 7.6 d'un côté, et commencer à réfléchir sur les orientations ultérieures d'un autre côté. Merci par avance de tes apports "à deux niveaux". "
Je reprend ici la discutions pour ne pas déborder sur le message d'Hardboiled...
Afficher la structure arborescente des sections dans les urls est exactement comme l'histoire des Gestion des erreurs 404 c'est la nomenclature utilisée et la logique.Au risque de me désavouer moi-même, l'impact au niveau du référencement n'est peut être pas évidant. Mais j'ai au moins un argument:
Quoi qu'il en soit, je suis intimement persuadé que ces deux paramètres (nom de section et nom de page) doivent rester différenciés par un séparateur fonctionnel : (/)
J'attends donc la version 7.6, et j'essayerais d'être aussi critique (dans les deux sens) que possible.
Ah que cette question me trotte dans la tête...
En relisant, cherchant, et comparant des centaines d'url différentes, je me suis rendu compte d'une chose, après plus d'un an d'utilisation de Yacs pour mon usage personnel et professionnel... Le numéro présent dans l'url, et en qui je voyais une nouvelle opportunité d'optimisation n'était pas une référence à la section parente de l'article, mais la référence à l'article en question ! (pourtant j'avais déjà fait cette constatation dans un post précédent, mais sans y faire réélement attention)
Dans ce cas, la séparation de ce chiffre dans un conteneur spécifique n'est absolument pas justifié !
Forcement, en ayant pris le problème à l'envers (ou en avance ?) j'ai eu du mal à comprendre tes réticences Bernard...
Mais, ce n'est pas pour cette raison que je vais arrêter d'être critiques
Autant je comprends maintenant ta question sur "l'utilité de la séparation hiérarchique du numéro/nick_name" autant j'aimerais à mon tour comprendre l'utilité de l'extension en .html
Je sens que je vais avoir droit à mon propre argumentaire, à savoir :"Logique et en usage"
Oui, mais l'ajout de l'extension n'apporte rien, ni en terme de clarté, ni en terme d'optimisation (une page en .html n'est pas mieux référencée, et cela allonge inutilement l'url)
Quoi qu'il en soit, j'ai toujours du mal à comprendre l'utilité de la modification de l'url actuelle. Pour avoir effectué quelques référencements, la précédente version est efficace, je ne comprend pas l'utilité d'une si grande modification pour un résultat probablement sans effet...
A part celui d'avoir à corriger une multitude de liens sur des sites externes...
Il y a surement un point qui m'échappe... Je cherche ma réponse ici : http://www.illiweb.com/manuel/Apache_1.3_VF/content-negotiation.html
ThierryP : Sans rentrer dans le réflexion, je pense que l'extension (peu importe laquelle) est nécessaire pour différencier rapidement une cible de type dossier (/) par rapport à une cible de type page (.extension).
La plupart du temps, les gens font abstraction du "/" final (à tort) auquel cas que devient la cible l'url ? Un dossier sans son "/" ou une page sans extension ? Avec l'extention, on peu corriger les erreurs de syntaxe pour l'oubli du "/" dans les cibles dossiers.
Je rappelle qu'une url se terminant par un "/" sous entends "/index.php" ou "/index.html" (etc, suivant les directives du serveur), ce qui est aussi une forme d'abus de syntaxe.
Le problème du numéro d'article, c'est pour les cas où l'article n'a pas de surnom mais aussi pour différencier les articles à surnoms identiques.
Pour l'intégration du numéro/nom de section, je crois savoir ce qui empêche son utilisation : les catégories. Car comment savoir si l'article se trouve dans une section, une sous-section ou une catégorie ? Dans les 2 cas, c'est bien l'article que l'on vise et non son emplacement qui devient obsolète.
Le but d'une url n'est pas de coller à la structure rigide du plan du site mais d'accéder à une cible par le plus court chemin, non ?
ThierryP: Normalement, le protocole HTTP dispose d'un atribut qui indique le type de l'objet renvoyé par le serveur. Le type MIME indiqué est "
text/html" s'il s'agit d'une page web, ou "image/gif" pour une image GIF, etc. De ce point de vue, il n'y a pas besoin d'inquer l'extension dans le lien lui-même.Sauf que, pour que ça marche bien, il faut un serveur configuré correctement, ce qui n'a pas été le cas pendant très longtemps. Donc les fabricants de navigateurs ont aussi pris l'habitude de regarder l'extension fournie, au cas où...
Il semble que Firefox 2 et IE 7 aient donné la priorité aux types MIME, qui sont d'ailleurs assez bien gérés par YACS. Pour les autres, je ne sais pas, et dans le doute j'ai mis
.html en plus. Et bien, il ne fallait pas...Je viens de retrouver une excellente (et ancienne) page de Tim Berner-Lee, très instructive :
Cool URIs don't change
Donc on est bien d'accord, je retire l'extension
.html hein ? Si même le grand Tim est d'accord, alors..." A propos des extensions de nom de fichier (web)
C'est quelque chose de très commun. Même l'extension ".html" est quelque chose qui changera avec le temps.
Vous ne pouvez pas utiliser le HTML pour une page pendant 20 années, mais vous pourriez souhaiter que les liens qui existent aujourd'hui pour cette page reste valables, même après 20 ans.
La façon canonique de faire des liens d'après le W3C est l'absence d'extensions. "
Donc si le père du Web le dit, je crois que l'extension .html n'a pas sa place dans yacs !
A, et merci pour le lien Bernard.
ThierryP: Je viens de mettre ce serveur à jour, pour voir ce que ça donne sans les extensions
.html, donc tout feed-back de bug est le bienvenu...Je suis attentif.
Pour l'instant aucun lien mort à te signaler.
L'idée du choix de la réécriture de l'url pour yacs 7.6 est une très bonne chose !
Un pas de plus est franchi.
Yacs, ou comment avoir le choix dans l'excellence...
Tu utilise Firefox Bernard ?
Teste le lien RSS sur la page d'accueil dans la barre d'adresse... Peut être un problème dû aux nouvelles urls ?
ThierryP: bien vu... J'ai le même problème en local, et donc je vais regarder la log Apache... à suivre...
