Changement de permalien et redirection (Créer un compte)

  • Statut : non résolu
4 sujets de 1 à 4 (sur un total de 4)
  • Auteur
    Messages
  • #480772
    gabier
    Participant
    Chevalier WordPress
    110 contributions

    Bonjour,

    Ma configuration WP actuelle
    – Version de WordPress : 2.9
    – Version de PHP/MySQL : 5
    – Thème utilisé : perso
    – Extensions en place : cforms, link checker, custom post limit
    – Nom de l’hebergeur : OVH
    – Adresse du site : http://www.chomage-et-monnaie.org

    Problème(s) rencontré(s) :

    Je voudrais passer de la structure par défaut des permaliens (monsite/?p=123) à un structure du genre monsite/an/mois/titre/. Simultanément je voudrais mettre en service les redirections adéquates pour éviter les « duplicate content » et conserver la valeur des liens des sites ou utilisateurs extérieurs vers mon site.
    Je me suis donc documenté sur les règles de réécritures dans le .htaccess, mais je tombe sur cet article du Codex dans lequel on dit

    When you create or update a « pretty » permalink structure, WordPress will generate rewrite rules and attempt to insert them into the proper .htaccess file. If it can’t, it will say something like You should update your .htaccess now and print out the rules for you to copy and paste into the file (put them at the end).

    D’abord je ne comprends pas bien ce que ça veut dire. Quelles redirections WordPress doit-il faire ? Et puis, j’ai essayé en local et il ne me dit rien du tout ni ne modifie le fichier .htaccess (j’ai bien vérifié que l’option « rewrite » est bien chargée dans XAMMP qui est mon serveur local).

    Je ne voudrais pas me louper lorsque je ferai le changement sur le site distant. Quelqu’un sait-il si WordPress fait quelque chose ou pas quand on change les permaliens ? Le document du Codex que j’ai cité n’est pas clair du tout là-dessus.

    🙂 Gabier

    Je rajoute ça parce que j’ai fait un essai en local en passant en url long et en appelant monsite/?p=123 (url ancien et « classique ». WordPress affiche le bon article et met dans la barre d’adresse l’url long. Ce qui voudrait dire qu’il y a bien redirection mais interne à WordPress. Ce qui serait parfait, mais est-ce sûr ?

    #720972
    gabier
    Participant
    Chevalier WordPress
    110 contributions

    Bonjour,
    N’ayant au aucune réponse, je ne peux savoir si personne ne sait ou si on estime que je devrais trouver tout seul. Alors j’ai avancé.
    Dans le premier cas mon expérience servira et dans le deuxième je voudrais tout de même être rassuré.

    J’ai supposé que WordPress ne pouvait faire ces redirections en local parce que en local je suis sous Windows et que sous ce système on ne peut régler les permissions de fichiers comme sous Unix (on a seulement lecture seule ou non).
    Bien que le fichier .htaccess ne soit pas en lecture seule, peut-être WordPress n’aime pas le statut du fichier et ne fait rien à cause de ça.

    Donc je me suis lancé et j’ai fait le changement d’URL sur le site distant, après avoir changé les permissions sur le fichier .htaccess de 644 à 664.
    Le changement d’URL s’est fait, et WordPress ne m’a rien dit, mais il a mis dans le fichier htaccess le code suivant

    # BEGIN WordPress
    
    RewriteEngine On
    RewriteBase /
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /index.php [L]
    
    # END WordPress

    Pour autant que ma faible science comprenne cette prose, ceci demande à rediriger tout fichier qui n’est pas un répertoire et dont le chemin n’existe pas, vers la page index de wordpress.

    Mais ceci ne redirige pas mes anciens url vers les nouveaux, ou alors je n’ai rien compris ?
    Pourtant, la redirection semble marcher, puisque si j’appelle une page avec l’ancienne structure de permalien, j’obtiens bien la bonne page avec la nouvelle structure de permalien.

    Alors quelqu’un peut-il m’aider à comprendre ? Dois-je faire quelque chose pour ne pas avoir de « duplicate content  » ou est-ce que c’est tout bon ?

    🙂 Gabier

    #720973
    gabier
    Participant
    Chevalier WordPress
    110 contributions

    Bonjour à tous,

    Je reformule ma question une nouvelle fois.

    Etant donné que, en cas de changement de structure des URL, WordPress traite le problème de redirection de manière interne (et non dans le fichier .htaccess), lequel de ces 2 comportements adopte-t-il lorsqu’il reçoit une requête avec le « vieux » URL ?

    1. Renvoyer directement la bonne page

    2. Envoyer une erreur 301 avec l’URL « alternate » (le « nouveau »), pour que le client appelle le « nouveau »

    Je n’ai trouvé nulle part la réponse à cette question. Or s’il fait comme en 2, c’est standard et je n’ai pas de problème. Tandis que s’il fait comme en 1. alors, comme les deux URL fonctionnent indépendamment, il y a « duplicate content » au sens de Googlebot et des autres robots.

    Personne ne sait ça ?

    🙂 Gabier

    #720974
    gabier
    Participant
    Chevalier WordPress
    110 contributions

    J’ai trouvé la réponse sur le forum de WordPress.com. Je vous en fais profiter.

    Wordpress envoie bien une erreur 301 avec le bon URL lorsqu’il reçoit une demande avec l’ancien URL, ou tout autre URL non conforme à l’URL en cours.
    Qui plus est, Google a proposé l’année dernière, pour éviter tous les problèmes de « duplicate content » générés par les multiples URL qui pointent sur la même chose, d’adopter le schéma suivant
    – Insertion dans la « Head » du document indexé d’une balise . Autrement dit le document contient le bon URL.
    – Renvoyer une erreur 301 avec l’URL canonique comme « alternate URL » pour tout URL qui pointe sur le même document avec un URL différent de l’URL canonique.

    Normalement WordPress se conforme à ce schéma (on peut retrouver la balise rel=’canonical’ dans la source des pages des posts), et il n’y a aucun problème de « duplicate content » à craindre lorsqu’on change la structure des permaliens.

    🙂 Gabier

4 sujets de 1 à 4 (sur un total de 4)
  • Vous devez être connecté pour répondre à ce sujet.