J'ai voulu répondre au ticket 2825, mais j'ai eu une erreur sur le REDMINE.
Donc voilà mon message
<quote>Salut, je pense que c'est une mauvaise idée.
Je ne sais pas comment cout en energie cette ligne, mais a mon avis on risque d'avoir des retours d'utilisateurs si on supprimer cela.
prenons un site créé en 2004 comme http://helene.lipietz.net : rien ne me garanti qu'il n'y a pas quelque part dans le monde des gens qui ont pointé sur une vieille URL en .php3.
Actuellement, avec le .htaccess, je suis sur que les gens ne tomberont pas sur du 404 mais seront redirigés. En revanche si on la supprime les gens auront des 404, sauf si je pense à la rétablir moi même.
Il ne me semble pas que comme compatibilité historique ce soit très lourd à gérer. Je ne vois rien qui justifie vraiment sa suppression.
</quote>
J’ai voulu répondre au ticket 2825, mais j’ai eu une erreur sur le REDMINE.
Les éléments qui me gênent sont les suivants :
que les urls dites « standard » dans SPIP 3 soient encore en standard — article.php3?id_article=12
que le serveur gère les urls en .php3
SPIP3 nécessite PHP5, donc garder ce hack est une mauvaise idée.
Ceux qui souhaitent garder les anciennes urls peuvent rajouter quelques lignes dans le .htaccess, mais à mon avis ça ne devrait pas figurer dans le htaccess.txt standard.
Ce fichier fait une réécriture et pas une redirection 301, donc du coup on ( + les moteurs de recherche) garde plusieurs versions d’une même page, ce qui est vraiment sale.
Cela ne donne pas une image moderne de SPIP
Vu que SPIP passe beaucoup d’éléments en modules, la compatibilité avec les urls en .php3 devrait devenir une contribution annexe, au même titre que les configurations pour nginx, Cherokee et autre…
J'ai voulu répondre au ticket 2825, mais j'ai eu une erreur sur le
REDMINE.
Les éléments qui me gênent sont les suivants :
- que les urls dites "standard" dans SPIP 3 soient encore en
/standard/ — article.php3?id_article=12
a) on peut les appeler "historiques" comme dans le plugin
- que le serveur gère les urls en .php3
SPIP3 nécessite PHP5, donc garder ce hack est une mauvaise idée.
- Ceux qui souhaitent garder les anciennes urls peuvent rajouter
quelques lignes dans le .htaccess, mais à mon avis ça ne devrait pas
figurer dans le htaccess.txt standard.
oui, mais encore faut-il que l'information soit bien documentés et explicite, hor pour le moment c'est un peu la galère
- Ce fichier fait une réécriture et pas une redirection 301, donc du
coup on ( + les moteurs de recherche) garde plusieurs versions d'une
même page, ce qui est vraiment sale.
ca ca peut se corriger
- Cela ne donne pas une image moderne de SPIP
cela donne l'image d'un logiciel qui a la préoccupation de l'archivistique
J'ai voulu répondre au ticket 2825, mais j'ai eu une erreur sur le
REDMINE.
Les éléments qui me gênent sont les suivants :
- que les urls dites "standard" dans SPIP 3 soient encore en
/standard/ — article.php3?id_article=12
a) on peut les appeler "historiques" comme dans le plugin
oui, mais le changement de nom introduit une rupture (minime certes) de compat, ce serait donc pour une 3.1
- que le serveur gère les urls en .php3
SPIP3 nécessite PHP5, donc garder ce hack est une mauvaise idée.
- Ceux qui souhaitent garder les anciennes urls peuvent rajouter
quelques lignes dans le .htaccess, mais à mon avis ça ne devrait pas
figurer dans le htaccess.txt standard.
oui, mais encore faut-il que l'information soit bien documentés et explicite, hor pour le moment c'est un peu la galère
ça coute vraiment pas grand chose de maintenir ces 3 lignes et ça évite effectivement de perdre des URLs...
- Ce fichier fait une réécriture et pas une redirection 301, donc du
coup on ( + les moteurs de recherche) garde plusieurs versions d'une
même page, ce qui est vraiment sale.
ca ca peut se corriger
Si on a changé de système d'URL, on a bien une 301 faite par SPIP vers la nouvelle URL il me semble, non ?
- Cela ne donne pas une image moderne de SPIP
cela donne l'image d'un logiciel qui a la préoccupation de l'archivistique
Vu que SPIP passe beaucoup d'éléments en modules, la compatibilité avec
les urls en .php3 devrait devenir une contribution annexe, au même titre
que les configurations pour nginx, Cherokee et autre..
Tout est question de dosage. Passer en module un gros morceau de code pour en faciliter la maintenance ça a un sens.
Sortir 2 lignes de htaccess qui assurent la compat ascendante sur ce motif ça parait assez peu productif, d'autant plus que le htaccess ne permet pas de surcharge ni d'inclusion. On va donc grandement compliquer les choses pour la prise en compte de ces urls, ou, plus probable, casser l'historique des urls des vieux sites. Ce qui est toujours gênant.
La vraie question est donc : qu'a-t-on vraiment à gagner à supprimer ces URLs ?
Je ne vois pas vraiment, à vrai dire...
oui, mais le changement de nom introduit une rupture (minime certes) de compat, ce serait donc pour une 3.1
à chaque fois qu’on fait une mise à jour on maudit tous ceux qui ont décidé à un moment donné d’une rupture de compat, aussi minime soit-elle. Expérience faite hier encore ! Donc, à moins d’une obligation majeure, c’est à éviter…
