aller vers les urls propres, un casse-tête chez Free ?

Général
1

Bonjour,

Après une phase de test assez intensive, j'ai malheureusement la confirmation de
ce que je craignais :

Un site qui avait des anciennes urls (/article.php3?id_article=XX), en Spip
1.8, chez Free (hébergeur ne permettant pas le mode rewrite, réécriture sur
Apache), ne peut pas :
- passer en url-propres QS en v 1.8 (donc pas possibilité de passer à des urls
propres, du fait de Free)
- passer en url-propres QS en v 1.9.0, tout en gardant le bénéfice des anciennes
url (connues des moteurs de recherche).

La contrib Balluche (qui permet des urls propres chez Free) marche bien sur la
1.8 et la 1.9.0, mais les anciennes adresses ne sont pas reconnues non plus
(erreur 404).

Tout ceci, selon ma compréhension, parce que :
- le mode Balluche utilise inc-public.php3 (et est donc incompatible avec les
anciennes adresses)
- le mode standard d'adresses de la 1.9.0 est la forme /spip.php?articleXX et
non pas /article.php3?id_article=XX ; ce qui fait que deux types d'adresses
fonctionnent bien (super), sauf que ce sont toutes les deux des formes d'url que
ne connaissent pas les moteurs... (cela ne répond donc pas au problème de faire
une transition vers les urls propres, pour les moteurs de recherche).

Plusieurs pistes :
1. la plus souple, et probablement pas très compliquée (??) : faire en sorte que
les anciennes adresses (je sais elles ne marchent plus depuis la 1.9.1, mais
cela permet une transition, le temps que les moteurs reconnaissent les
nouvelles) soient utilisables en même temps que les urls propres QS.

2. utiliser les bouts de code nécessaires, sur la 1.9.0 pour permettre les urls
propres QS sur la 1.8.3, ce qui les rendraient compatibles avec les anciennes
adresses

3. ??? le fichier inc-urls.php3 à la racine du site pourrait-il être utilisé
pour rétablir les anciennes adresses /article.php3?id_article=XX comme
'standard', au lieu de /spip.php?article1 ???

Merci par avance,
espérant que j'ai été assez clair

Marc

Pour info et 'démo', site 1.9.0, avec à la fois :
-QS : http://m.debeaumont.free.fr/?Les_specificites_de_Spip_en_general_chez_Free
- et "page" : http://m.debeaumont.free.fr/spip.php?article2
mais pas les "anciennes" : http://m.debeaumont.free.fr/article.php3?id_article=2

Doc Spip "Utiliser des URLs personnalisées" :
http://www.spip.net/fr_article765.html

Contrib Balluche :
http://www.spip-contrib.net/La-reecriture-d-URL-native-de-SPIP

2

Bonjour,

A des fins de compatibilité (ascendante) je cherche à :
- rendre compréhensibles les anciennes adresses urls /article.php3?id_article=XX
    dans la 1.9.0 (configurée en mode propres QS)
- ou bien à passer au mode propres QS dans la 1.8.0 'tout en gardant la
lecture des urls /article.php3?id_article=XX )

Y a t il quelqu'un qui pourrait m'aider à savoir laquelle des deux démarches a
le plus de chance d'être réalisée rapidement ?

J'ai du mal avec les fichiers : /url/propres-qs.php , /url/propres-qs.php ,
/url/standard.php , /url/page.php etc., que j'aimerais modifier ou compléter
dans la 1.9.0 pour reconnaitre les anciennes adresses (au lieu de reconaitre les
adresses spip.php?articleXX)
ou récupérer une partie de ces codes pour passer aux urls propres QS dans la
1.8.3 (tout en gardant la compréhension des urls /article.php3?id_article=XX .

Peut-être une piste (complémentaire ?) serait-elle de :
DANS LA 1.8
- créer un champ url_standard dans la BD
- faire une moulinette qui remplirait ce champ pour les articles actuels, avec
les anciennes adresses /article.php3?id_article=XX
MIGRER à la 1.9.0
- passer aux urls propres QS
- et modifier le code pour autoriser la lecture des anciennes adresses (mais je
ne vois pas trop alors comment me servir du champ de la BD)

Si quelqu'un d'entre vous pouvait me mettre sur la voie, ce serait super,
merci

Marc
-------------------------------------
Selon m.debeaumont@free.fr:

Bonjour,

Après une phase de test assez intensive, j'ai malheureusement la confirmation
de
ce que je craignais :

Un site qui avait des anciennes urls (/article.php3?id_article=XX), en Spip
1.8, chez Free (hébergeur ne permettant pas le mode rewrite, réécriture sur
Apache), ne peut pas :
- passer en url-propres QS en v 1.8 (donc pas possibilité de passer à des
urls
propres, du fait de Free)
- passer en url-propres QS en v 1.9.0, tout en gardant le bénéfice des
anciennes
url (connues des moteurs de recherche).

La contrib Balluche (qui permet des urls propres chez Free) marche bien sur
la
1.8 et la 1.9.0, mais les anciennes adresses ne sont pas reconnues non plus
(erreur 404).

Tout ceci, selon ma compréhension, parce que :
- le mode Balluche utilise inc-public.php3 (et est donc incompatible avec les
anciennes adresses)
- le mode standard d'adresses de la 1.9.0 est la forme /spip.php?articleXX et
non pas /article.php3?id_article=XX ; ce qui fait que deux types d'adresses
fonctionnent bien (super), sauf que ce sont toutes les deux des formes d'url
que
ne connaissent pas les moteurs... (cela ne répond donc pas au problème de
faire
une transition vers les urls propres, pour les moteurs de recherche).

Plusieurs pistes :
1. la plus souple, et probablement pas très compliquée (??) : faire en sorte
que
les anciennes adresses (je sais elles ne marchent plus depuis la 1.9.1, mais
cela permet une transition, le temps que les moteurs reconnaissent les
nouvelles) soient utilisables en même temps que les urls propres QS.

2. utiliser les bouts de code nécessaires, sur la 1.9.0 pour permettre les
urls
propres QS sur la 1.8.3, ce qui les rendraient compatibles avec les anciennes
adresses

3. ??? le fichier inc-urls.php3 à la racine du site pourrait-il être utilisé
pour rétablir les anciennes adresses /article.php3?id_article=XX comme
'standard', au lieu de /spip.php?article1 ???

Merci par avance,
espérant que j'ai été assez clair

Marc

Pour info et 'démo', site 1.9.0, avec à la fois :
-QS :
http://m.debeaumont.free.fr/?Les_specificites_de_Spip_en_general_chez_Free
- et "page" : http://m.debeaumont.free.fr/spip.php?article2
mais pas les "anciennes" :
http://m.debeaumont.free.fr/article.php3?id_article=2

Doc Spip "Utiliser des URLs personnalisées" :
Utiliser des URLs personnalisées - SPIP

Contrib Balluche :
http://www.spip-contrib.net/La-reecriture-d-URL-native-de-SPIP
_______________________________________________
liste spip
spip@rezo.net - désabonnement : spip-off@rezo.net

Infos et archives : http://listes.rezo.net/mailman/listinfo/spip

Documentation de SPIP : http://www.spip.net/

irc://irc.freenode.net/spip ou
http://embed.mibbit.com/?server=irc.freenode.net&channel=%23spip

3

S'lt

Le plus simple ne sertait il pas de modifier ton .htaccess directement
avec une ligne du genre :

RewriteRule ^(.+)\.php3(..+)$ /$1.php$2 [R=301,L]

Cette écriture est à mettre avant les autres, elles sont lues séquentiellement
Cela signifie tout chaine avec .php3 est réécrite en .php en
conservant ce qui precéde et ce qui suit
R=301 signifiant redirection permanente

C'est à valider car non testée mais c'est une piste

4

Merci beaucoup pour cete réponse,

mais c'est justement ce qui n'est pas possible avec les serveurs Free.
C'est bien pour cela qu'il y a problème,
merci de toute façon,

Marc

Selon "cam.lafit@azerttyu.net" <cam.lafit@azerttyu.net>:

S'lt

Le plus simple ne serait il pas de modifier ton .htaccess directement
avec une ligne du genre :

RewriteRule ^(.+)\.php3(..+)$ /$1.php$2 [R=301,L]

Cette écriture est à mettre avant les autres, elles sont lues
séquentiellement
Cela signifie tout chaine avec .php3 est réécrite en .php en
conservant ce qui precéde et ce qui suit
R=301 signifiant redirection permanente

C'est à valider car non testée mais c'est une piste

5

Bonsoir,

J'ai peut-être trouvé un moyen de contourner la difficulté.
Une astuce, mais qui se traduit par une migration un peu compliquée, et longue;

Le tableau que j'avais réalisé dans l'article :
http://m.debeaumont.free.fr/?Les_specificites_de_Spip_en_general_chez_Free
permet d'imaginer une transition un peu compliquée, en plusieurs étapes, mais
qui aurait l'avantage de ne pas perdre (trop) de référencement avec les moteurs
de recherche.

L'idée est d'utiliser les urls Balluche comme urls de transition :
- passer des anciennes urls aux urls Balluche sur 1.8.3 (version qui reconnait
alors les anciennes adresses), (et attendre que les moteurs de recherche citent
les nouvelles urls Balluche)
- migrer vers 1.9.0 toujours avec ces urls Balluche (à un moment où les moteurs
de recherche ont fait la modif dans leurs bases de données, vers ces adresses
Balluche)
- puis passer aux urls propres-qs (il semble que les adresses Balluche restent
alors reconnues), toujours avec la 1.9.0

Il serait alors possible de rester plus tard avec ces urls propres-qs pour
passer aux versions ultérieures : 1.9.1, 1.9.2, 1.9.3, 2.0...

Le tout est de savoir combien de temps est nécessaire aux moteurs de recherche
pour faire la conversion : un mois, deux mois ? voire plus ? La durée de
migration globale serait alors un multiple (2 normalement, peut-être 3) de cette
durée.

Il faudrait faire des tests systématiques pour vérifier que c'est possible. Ce
que je peux faire.

Avant cela, quelqu'un peut-il me dire :
- l'ordre de grandeur de la durée nécessaire aux moteurs de recherche pour faire
la conversion dans leurs BD ?
- et s'il y aurait une faille dans ce raisonnement ? Ou un inconvénient que je
n'ai pas vu ?

merci par avance,

Marc

Selon m.debeaumont@free.fr:

Bonjour,

A des fins de compatibilité (ascendante) je cherche à :
- rendre compréhensibles les anciennes adresses urls
/article.php3?id_article=XX
    dans la 1.9.0 (configurée en mode propres QS)
- ou bien à passer au mode propres QS dans la 1.8.0 'tout en gardant la
lecture des urls /article.php3?id_article=XX )

Y a t il quelqu'un qui pourrait m'aider à savoir laquelle des deux démarches
a
le plus de chance d'être réalisée rapidement ?

J'ai du mal avec les fichiers : /url/propres-qs.php , /url/propres-qs.php ,
/url/standard.php , /url/page.php etc., que j'aimerais modifier ou compléter
dans la 1.9.0 pour reconnaitre les anciennes adresses (au lieu de reconaitre
les
adresses spip.php?articleXX)
ou récupérer une partie de ces codes pour passer aux urls propres QS dans la
1.8.3 (tout en gardant la compréhension des urls /article.php3?id_article=XX
.

Peut-être une piste (complémentaire ?) serait-elle de :
DANS LA 1.8
- créer un champ url_standard dans la BD
- faire une moulinette qui remplirait ce champ pour les articles actuels,
avec
les anciennes adresses /article.php3?id_article=XX
MIGRER à la 1.9.0
- passer aux urls propres QS
- et modifier le code pour autoriser la lecture des anciennes adresses (mais
je
ne vois pas trop alors comment me servir du champ de la BD)

Si quelqu'un d'entre vous pouvait me mettre sur la voie, ce serait super,
merci

Marc
-------------------------------------
Selon m.debeaumont@free.fr:

> Bonjour,
>
> Après une phase de test assez intensive, j'ai malheureusement la
confirmation
> de
> ce que je craignais :
>
> Un site qui avait des anciennes urls (/article.php3?id_article=XX), en
Spip
> 1.8, chez Free (hébergeur ne permettant pas le mode rewrite, réécriture sur
> Apache), ne peut pas :
> - passer en url-propres QS en v 1.8 (donc pas possibilité de passer à des
> urls
> propres, du fait de Free)
> - passer en url-propres QS en v 1.9.0, tout en gardant le bénéfice des
> anciennes
> url (connues des moteurs de recherche).
>
> La contrib Balluche (qui permet des urls propres chez Free) marche bien sur
> la
> 1.8 et la 1.9.0, mais les anciennes adresses ne sont pas reconnues non plus
> (erreur 404).
>
> Tout ceci, selon ma compréhension, parce que :
> - le mode Balluche utilise inc-public.php3 (et est donc incompatible avec
les
> anciennes adresses)
> - le mode standard d'adresses de la 1.9.0 est la forme /spip.php?articleXX
et
> non pas /article.php3?id_article=XX ; ce qui fait que deux types d'adresses
> fonctionnent bien (super), sauf que ce sont toutes les deux des formes
d'url
> que
> ne connaissent pas les moteurs... (cela ne répond donc pas au problème de
> faire
> une transition vers les urls propres, pour les moteurs de recherche).
>
> Plusieurs pistes :
> 1. la plus souple, et probablement pas très compliquée (??) : faire en
sorte
> que
> les anciennes adresses (je sais elles ne marchent plus depuis la 1.9.1,
mais
> cela permet une transition, le temps que les moteurs reconnaissent les
> nouvelles) soient utilisables en même temps que les urls propres QS.
>
> 2. utiliser les bouts de code nécessaires, sur la 1.9.0 pour permettre les
> urls
> propres QS sur la 1.8.3, ce qui les rendraient compatibles avec les
anciennes
> adresses
>
> 3. ??? le fichier inc-urls.php3 à la racine du site pourrait-il être
utilisé
> pour rétablir les anciennes adresses /article.php3?id_article=XX comme
> 'standard', au lieu de /spip.php?article1 ???
>
> Merci par avance,
> espérant que j'ai été assez clair
>
> Marc
>
> Pour info et 'démo', site 1.9.0, avec à la fois :
> -QS :
> http://m.debeaumont.free.fr/?Les_specificites_de_Spip_en_general_chez_Free
> - et "page" : http://m.debeaumont.free.fr/spip.php?article2
> mais pas les "anciennes" :
> http://m.debeaumont.free.fr/article.php3?id_article=2
>
> Doc Spip "Utiliser des URLs personnalisées" :
> Utiliser des URLs personnalisées - SPIP
>
> Contrib Balluche :
> http://www.spip-contrib.net/La-reecriture-d-URL-native-de-SPIP
> _______________________________________________
> liste spip
> spip@rezo.net - désabonnement : spip-off@rezo.net
>
> Infos et archives : http://listes.rezo.net/mailman/listinfo/spip
>
> Documentation de SPIP : http://www.spip.net/
>
> irc://irc.freenode.net/spip ou
> http://embed.mibbit.com/?server=irc.freenode.net&channel=%23spip
>

6

m.debeaumont@free.fr a écrit :

Bonjour,

Après une phase de test assez intensive, j'ai malheureusement la confirmation de
ce que je craignais :

Un site qui avait des anciennes urls (/article.php3?id_article=XX), en Spip
1.8, chez Free (hébergeur ne permettant pas le mode rewrite, réécriture sur
Apache), ne peut pas :
- passer en url-propres QS en v 1.8 (donc pas possibilité de passer à des urls
propres, du fait de Free)
- passer en url-propres QS en v 1.9.0, tout en gardant le bénéfice des anciennes
url (connues des moteurs de recherche).

chez free pas de rewriterules, donc soit tu passes par une 404 personnalisée qui retraite derriere, soit tu mets des article.php3, rubrique.php3... qui font un redirect (301) sur ?articleXXX, ?rubriqueXXX ... qui feront un redirect sur l'url propre.
au final l'ancienne adresse repond et ca informe les moteurs de la nouvelle.

@++

7

S'lt

As tu essayé ce genre de solution ?

http://lionel.suz.free.fr/index.php?id=about&sub=blog&entry=1076844339

8

merci bien à Stéphane et à cam.lafit,

car ces deux réponses sont très complémentaires, et très instructives pour moi
qui n'y connais pas grand chose en redirection.

Ces deux réponses suffiront peut-être pour faire une redirection en passant par
une page erreur404 personnalisée, mais je ne sais pas ce à quoi fait allusion
lionel.suz quand il écrivait, sur sa page
(Comment faire de l'URL rewriting sur Free.fr - LSZ Blog) :

Note:
La redirection par la fonction header() n'est pas nécessairement une mauvaise
idée, mais celà risque de poser des problèmes pour l'indexation par Google. J'ai
donc choisi de lire directement dans un flux (fonction fopen() et fgetc() en
php).

Quelqu'un sait-il ce qu'il fait pour "lire directement dans un flux (fonction
fopen() et fgetc() en php" ?

Marc

---------------------------
Selon "cam.lafit@azerttyu.net" <cam.lafit@azerttyu.net>:

S'lt

As tu essayé ce genre de solution ?

Comment faire de l'URL rewriting sur Free.fr - LSZ Blog

---------------------------
De: Stephane <stephane@rezo.net>

Objet: Re: [Spip] aller vers les urls propres, un casse-tête chez Free ?

m.debeaumont@free.fr a écrit :

Bonjour,

Après une phase de test assez intensive, j'ai malheureusement la confirmation

de

ce que je craignais :

Un site qui avait des anciennes urls (/article.php3?id_article=XX), en Spip
1.8, chez Free (hébergeur ne permettant pas le mode rewrite, réécriture sur
Apache), ne peut pas :
- passer en url-propres QS en v 1.8 (donc pas possibilité de passer à des urls
propres, du fait de Free)
- passer en url-propres QS en v 1.9.0, tout en gardant le bénéfice des

anciennes

url (connues des moteurs de recherche).

chez free pas de rewriterules, donc soit tu passes par une 404
personnalisée qui retraite derriere, soit tu mets des article.php3,
rubrique.php3... qui font un redirect (301) sur ?articleXXX,
?rubriqueXXX ... qui feront un redirect sur l'url propre.
au final l'ancienne adresse repond et ca informe les moteurs de la nouvelle.

@++

9

Bonjour

Quelqu'un sait-il ce qu'il fait pour "lire directement dans un flux (fonction
fopen() et fgetc() en php" ?

Je pense que là je vais me contenter d'un RTFM

Km

10

merci bien de cette réponse, peut-être que cela m'aidera,

même si je n'ai tjs pas compris ce qu'il s'agit de faire,
cad pourquoi lire un flux, et quel flux ?

Marc
-----------------
Selon "cam.lafit@azerttyu.net" <cam.lafit@azerttyu.net>:

Bonjour
> Quelqu'un sait-il ce qu'il fait pour "lire directement dans un flux
(fonction
> fopen() et fgetc() en php" ?

Je pense que là je vais me contenter d'un RTFM
PHP: fopen - Manual
PHP: fgetc - Manual

Km

11

m.debeaumont@free.fr a écrit :

merci bien de cette réponse, peut-être que cela m'aidera,

même si je n'ai tjs pas compris ce qu'il s'agit de faire,
cad pourquoi lire un flux, et quel flux ?
  

le flux, ce sont les données renvoyées par le serveur.
lorsqu'on contacte un serveur web, il retourne des entetes puis le flux.
dès que le flux est commencé, tu ne peux plus envoyer d'entetes.

si dans ta page article.php3, tu fais un fopen de spip.php?page=article, ca marchera, mais google continuera à utiliser cette adresse plutot que l'autre.
si tu fais une redirection, cad que dans les entetes http renvoyées le serveur disent "cette page correspond à cette autre adresse", si l'entete precise 301, il ajoute "et c'est definitif".
la google donnera la nouvelle adresse dans les resultats de recherche et fera glisser l'indexation (et le ranking) d'une page à l'autre

bref, amha, les redirections 301, c'est mieux.

@++

12

merci beaucoup pour ces explications lumineuses !

Cela répond vraiment à mes questions,
même si je ne sais pas encore comment faire une redirection 301.

J'imagine pour cela que mon bonheur se trouve dans le paragraphe
"Redirection dans un script serveur (PHP, ASP, etc.)" de la page :
http://74.125.39.104/search?q=cache:DsHEqZtwveEJ:www.webrankinfo.com/referencement/liens/redirections.php+redirection+301&hl=fr&ct=clnk&cd=1&gl=fr&lr=lang_fr

utilisation de la fonction header() en PHP
(n'allez pas à la ligne après "header(") :

header(
"Status: 301 Moved Permanently", false, 301);
header(
"Location: http://www.votresite.com/unepage.htm&quot;\);
exit();

Merci vivement !

Marc
--------------------------------------

Selon Stephane <stephane@rezo.net>:

m.debeaumont@free.fr a écrit :
> merci bien de cette réponse, peut-être que cela m'aidera,
>
> même si je n'ai tjs pas compris ce qu'il s'agit de faire,
> cad pourquoi lire un flux, et quel flux ?
>
le flux, ce sont les données renvoyées par le serveur.
lorsqu'on contacte un serveur web, il retourne des entetes puis le flux.
dès que le flux est commencé, tu ne peux plus envoyer d'entetes.

si dans ta page article.php3, tu fais un fopen de spip.php?page=article,
ca marchera, mais google continuera à utiliser cette adresse plutot que
l'autre.
si tu fais une redirection, cad que dans les entetes http renvoyées le
serveur disent "cette page correspond à cette autre adresse", si
l'entete precise 301, il ajoute "et c'est definitif".
la google donnera la nouvelle adresse dans les resultats de recherche et
fera glisser l'indexation (et le ranking) d'une page à l'autre

bref, amha, les redirections 301, c'est mieux.

@++

13

rebonjour,

Parallèlement aux réponses reçues ici, j'avais été amené à creuser un peu le
fonctionnement de "propres.php" (utilisé par propres-qs.php). Et ce code semble
comprendre la lecture des anciennes urls (avec php3) et des urls de type "page"
(spip.php?articleXX).

Le code est donc supposé faire (dans les premières lignes du code que je joins
ci-dessous) ce que je souhaite : pouvoir décoder les anciennes adresses .php3
...

Si ce décodage ne se fait pas, ce serait un bug de Spip 1.9.0, probablement pas
très difficile de corriger, puisque ce code a dû fonctionner auparavant...

J'ai voulu vérifier, en utilisant le code "propres.php" de la 1.9.1, que si bug
il y a eu avec la 1.9.0 il n'a pas été corrigé dans cette version ultérieure (je
n'ai pas essayé avec les versions au-delà car il y a peut-être d'autres
changements + importants par ailleurs).

N'ayant pu encore me replonger dans le fonctionnement de pregmatch (assez
complexe), j'ai cru comprendre que, dans les lignes encadrées de tirets ---,
$type = $regs[2] semble plus plausible que = $regs[3], et cela a l'air de donner
un type d'objet *article*, au lieu de *.php3*

Ce que je me suis empressé de tester... mais sans le résultat souhaité !
(ça aurait été trop beau, trop facile !)
toujours la même erreur 404, mais peut-être est-ce une erreur de ce genre ??

J'imagine qu'il y a parmi les lecteurs des personnes qui vont tout de suite voir
mon erreur, ou peut-être là où il y aurait un bug,

Merci par avance,

Marc

function recuperer_parametres_url(&$fond, $url) {
  global $contexte;
  $id_objet = 0;

  // Migration depuis anciennes URLs ?
  if ($GLOBALS['_SERVER']['REQUEST_METHOD'] != 'POST' AND
  (preg_match(
  ',(^|/)(article|breve|rubrique|mot|auteur|site)(\.php3?|[0-9]+\.html)'
  .'([?&].*)?$,', $url, $regs)
  )) {
--------------------------------------------------------------
  $type = $regs[3];
    $id_objet = intval($GLOBALS[$id_table_objet = id_table_objet($type)]);
  }
---------------------------------------------------------------
  /* Compatibilite urls-page */
  else if (preg_match(
  ',[?/&](article|breve|rubrique|mot|auteur|site)[=]?([0-9]+),',
  $url, $regs)) {
    $type = $regs[1];
    $id_objet = $regs[2];
  }

  if ($id_objet) {
    $func = "generer_url_$type";
    $url_propre = $func($id_objet);
    if (strlen($url_propre)
    AND !strstr($url,$url_propre)) {
      include_spip('inc/headers');
      http_status(301);
      // recuperer les arguments supplementaires (&debut_xxx=...)
      $reste = preg_replace('/^&/','?',
        preg_replace("/[?&]$id_table_objet=$id_objet/",'',$regs[5]));
      redirige_par_entete("$url_propre$reste");
    }
  }
  /* Fin compatibilite anciennes urls */

14

Bonjour,

0. je fais suite, avec un peu de retard, à un message de ma part. Résolu depuis.

En fait j'avais fait une "erreur de débutant", les fichiers article.php3,(etc.)
n'étant pas, contrairement à ce que je pensais, à la racine du site.
=> erreur "404" bien évidemment !
[Voir le message ultérieur que j'envoie à la liste, pour proposer de changer une
formulation dans la doc, pour éviter ce genre de déboires à d'autres]

Ayant fait l'ajout de ces fichiers (article.php3, rubrique.php3,etc.) l'erreur
"404" a disparu, mais je n'obtenais pas la redirection "301" souhaitée :
l'adresse affichée dans le navigateur était toujours du genre :
article.php3?id_article=X.

Le bug de la 1.9 (jusque dans la 1.9.2), est dans "propres.php".
=> Où signaler l'erreur ? à qui ?

1. Il suffit de remplacer, dans le pregmatch cité dans mon message précédent
(voir ci-dessous, juste au dessus des premiers tirets)
',(^|/)(article|breve|rubrique|mot|auteur|site)(\.php3?|[0-9]+\.html)'
.'([?&].*)?$,'
par :
',(^|/)((article|breve|rubrique|mot|auteur|site)(\.php3?|[0-9]+\.html)
([?&].*)?)$,'

pour que la redirection se fasse, sans problème.

2. Seule question en suspend : comment être sûr (vérifier) que les moteurs de
recherche perçoivent bien cette redirection 301 comme permanente ?

J'ai en effet lu qq part qu'il fallait compléter, dans headers.php, la ligne
      301 => '301 Moved Permanently',
par 301 => '301 Moved Permanently', false, 301,
parce que c'est nécessaire pour certains serveurs.

Merci par avance,

Marc

Pour précisions (et démo), l'article :
http://m.debeaumont.free.fr/?Des_adresses_URLs_propres_pour_Spip_chez_Free
et les les urls tests :
http://m.debeaumont.free.fr/article.php3?id_article=2 qui redirige vers :
http://m.debeaumont.free.fr/?Des_adresses_URLs_propres_pour_Spip_chez_Free
------------------------------------------------------------
Selon m.debeaumont@free.fr:

rebonjour,

... j'avais été amené à creuser un peu le fonctionnement de "propres.php"
(utilisé par propres-qs.php). Et ce code semble comprendre la lecture des
anciennes urls (avec php3) et des urls de type "page" (spip.php?articleXX).

Le code est donc supposé faire (dans les premières lignes du code que je
joins ci-dessous) ce que je souhaite : pouvoir décoder les adresses .php3 ...

Si ce décodage ne se fait pas, ce serait un bug de Spip 1.9.0, probablement
pas très difficile de corriger, puisque ce code a dû fonctionner auparavant...

J'ai voulu vérifier, en utilisant le code "propres.php" de la 1.9.1, que si
bug il y a eu avec la 1.9.0, il n'a pas été corrigé dans cette version
ultérieure.

N'ayant pu encore me replonger dans le fonctionnement de pregmatch (assez
complexe), j'ai cru comprendre que, dans les lignes encadrées de tirets ---,
$type = $regs[2] semble plus plausible que = $regs[3], et cela a l'air de
donner un type d'objet *article*, au lieu de *.php3*

Ce que je me suis empressé de tester... mais sans le résultat souhaité !
(ça aurait été trop beau, trop facile !)
toujours la même erreur 404, mais peut-être est-ce une erreur de ce genre ??

J'imagine qu'il y a parmi les lecteurs des personnes qui vont tout de suite
voir mon erreur, ou peut-être là où il y aurait un bug,

Merci par avance,

Marc

function recuperer_parametres_url(&$fond, $url) {
  global $contexte;
  $id_objet = 0;

  // Migration depuis anciennes URLs ?
  if ($GLOBALS['_SERVER']['REQUEST_METHOD'] != 'POST' AND
  (preg_match(
  ',(^|/)(article|breve|rubrique|mot|auteur|site)(\.php3?|[0-9]+\.html)'
  .'([?&].*)?$,', $url, $regs)
  )) {
--------------------------------------------------------------
  $type = $regs[3];
    $id_objet = intval($GLOBALS[$id_table_objet = id_table_objet($type)]);
  }
---------------------------------------------------------------
  /* Compatibilite urls-page */

15

Bonjour, (merci à Stéphane de faire suivre à qui de droit)

Ayant lu un peu trop vite la doc, j'ai fait une erreur qui m'a fait perdre pas
mal de temps.

Je propose de *changer un (seul) mot* dans la page :
www.spip.net/fr_article3368.html
http://209.85.135.104/search?q=cache:RrwaQmz26dAJ:www.spip.net/fr_article3368.html+"si+vous+laissez+les+anciens+fichiers+article.php3"&hl=fr&ct=clnk&cd=1&gl=fr&lr=lang_fr)

"dans le cas d’une migration, si vous *laissez* les anciens fichiers
article.php3 etc à la racine, ils continuent à fonctionner grâce au fichier
fantôme inc-public.php3 — mais attention cette compatibilité disparaîtra avec la
version suivante de SPIP."

de remplacer en fait le mot "laissez" par "recopiez".
Car la procédure de migration vers la 1.9 propose d'enlever "tous les fichiers
et dossiers" du site existant...

Et j'avais cru comprendre qu'il suffirait de suivre cette procédure, et que je
n'aurai pas à recopier ces fichiers article.php3 (puisqu'ils seraient laissés à
la racine lors de la procédure)... grave erreur !

Ce message donc pour éviter ce genre de déboires à d'autres, et pour éviter que
les prochaines docs ne reproduisent cette formulation ambigüe.

Merci bien,

Marc

16

Bonjour,

En plus du bug constaté dans la 1.9. et signalé dans mon message précédent
auquel je réponds ici, j'ai été amené à découvrir un bug dans la version 1.8.3
(et 1.8.3a). Qui peut se constater sur le Web, sur des adresses urls comme :
- http://tic.regionreunion.com/article.php3 ?id_article=5
=> Fatal error : Call to undefined function : http_status() in
/var/www/vhosts/regionreunion.com/subdomains/tic/httpdocs/inc-urls-propres.php3
on line 201
- ou : http://www.uneautreinformatique.com/rubrique.php3 ?id_rubrique=7
=> Fatal error : Call to undefined function http_status() in
/home/uaiv3/www/inc-urls-propres.php3 on line 201

D'autres améliorations de code (propres.php, inc-urls-propres.php3, headers.php,
inc-urls-balluche.php3) sont aussi proposées.

Les modifs, fichiers à télécharger et explications sont disponibles aux pages :
- http://m.debeaumont.free.fr/?Des_adresses_URLs_propres_pour_Spip_chez_Free
- http://m.debeaumont.free.fr/?Urls-propres-et-versions-de-Spip

mais contrairement au titre de ces articles, les améliorations de "propres.php"
et "inc-urls-propres.php3" sont plus générales (que Free ou autres hébergeurs
limitant les fonctionnalités de leur hébergement), elles concernent donc tous
les utilisateurs de Spip.

Une des améliorations de "propres.php" permet d'avoir un code plus rapide, et
surtout d'éviter qu'un article nommé "article3 blabla" ne puisse pas être
atteint par "spip.php?articleN", où N est le n° de cet article dans la BD.
Evidemment une telle appellation n'est pas courante, sauf quand on fait des
tests, et cela est très déconcertant, car on ne suspecte pas alors le code
"propres.php" d'être responsable de l'erreur 404 provoquée.

Si la modif n'est pas faite dans le code, il faudrait faire une modif dans la
doc, pour dire aux utilisateurs de Spip qu'il ne faut pas utiliser des titres
comme : "article3 blabla", "rubrique3 blabla", "breve3 blabla", etc.

A vrai dire je ne sais à qui envoyer ce message, merci de me le dire, à défaut
de faire suivre à la bonne personne.

Marc

Selon m.debeaumont@free.fr:

Bonjour,

0. je fais suite, avec retard, à un message de ma part. Résolu depuis.
Ayant fait l'ajout des fichiers (article.php3, rubrique.php3,etc.) nécessaires
à la racine du site, l'erreur "404" a disparu, mais je n'obtenais pas la
redirection "301" souhaitée, l'adresse affichée dans le navigateur était
toujours du genre : article.php3?id_article=X.

Le bug de la 1.9 (jusque dans la 1.9.2), est dans "propres.php".
=> Où signaler l'erreur ? à qui ?

1. Il suffit de remplacer, dans le pregmatch cité dans mon message précédent
(voir ci-dessous, juste au dessus des premiers tirets)
',(^|/)(article|breve|rubrique|mot|auteur|site)(\.php3?|[0-9]+\.html)'
.'([?&].*)?$,'
par :
',(^|/)((article|breve|rubrique|mot|auteur|site)(\.php3?|[0-9]+\.html)
([?&].*)?)$,'

pour que la redirection se fasse, sans problème.

2. Seule question en suspend : comment être sûr (vérifier) que les moteurs de
recherche perçoivent bien cette redirection 301 comme permanente ?

J'ai en effet lu qq part qu'il fallait compléter, dans headers.php, la ligne
      301 => '301 Moved Permanently',
par 301 => '301 Moved Permanently', false, 301,
parce que c'est nécessaire pour certains serveurs.

Merci par avance,

Marc

Pour précisions (et démo), l'article :
http://m.debeaumont.free.fr/?Des_adresses_URLs_propres_pour_Spip_chez_Free
et les les urls tests :
http://m.debeaumont.free.fr/article.php3?id_article=2 qui redirige vers :
http://m.debeaumont.free.fr/?Des_adresses_URLs_propres_pour_Spip_chez_Free