[Résolu] Réinstallation d’un site à partir d’une sauvegarde, rooting cassé

  • WordPress :4.9.4
  • Statut : résolu
11 sujets de 1 à 11 (sur un total de 11)
  • Auteur
    Messages
  • #2187499
    XtOf
    Participant
    Padawan WordPress
    50 contributions

    Bonjour,

    Cela fait 2 fois que je tente de réinstaller un site à partir d’une sauvegarde à la suite d’un changement d’hébergeur, sans succès…

    L’url du site est http://www.rers-landivisiau.fr

    Mon problème est que je ne peux plus accéder qu’à la page d’accueil, le rooting des pages internes semble cassé.

    Pour réinstaller le site, j’ai fait une nouvelle installation de WP, version 4.9.8 fr il me semble, celle que j’ai trouvé hier ici même.

    J’ai réinstallé le thème et les extensions que j’avais, puis j’ai inséré dans la base de données les données de la base de données du site sauvegardées.

    Quelqu’un verrait-il pourquoi mes 2 tentatives de réinstallation aboutissent au même échec, alors que pourtant j’ai réussi par le passé la manip?

     

    #2187645
    XtOf
    Participant
    Padawan WordPress
    50 contributions

    Pas moyen de modifier le titre… Je voulais parler de routing, pas de « rooting », mais je ne sais pas si le terme convient pour WP. Disons plutôt le système de permaliens.

    J’ai parlé de cela car lors de ma 2ème installation, j’ai tenté de paramétrer au maximum le site comme je le voulais avant de restaurer la base de données.

    Bizarrement, je n’ai pas trouvé le choix de permalien à ma convenance, c’est à dire nom-de-domaine/titre-de-larticle, du coup j’ai pris la proposition qui s’en approchait le plus: nom-de-domaine/index.php/titre-de-larticle.

    Et donc une fois restaurée la base de données, seule la page d’accueil fonctionne. Mais dans la barre d’adresse du navigateur, lorsque je teste de modifier « nom-de-domaine/titre-de-larticle » par « nom-de-domaine/index.php/titre-de-larticle », j’observe une redirection qui rétablit l’url « nom-de-domaine/titre-de-larticle ».

    Je me pose donc la question si par un moyen qui m’échapperait, le système de permaliens que j’avais configuré avant la restauration de la base de données n’aurait pas « survécu » à l’écrasement de la base de données.

    #2187718
    Li-An
    Modérateur
    Maître WordPress
    20215 contributions

    Bonjour, les permaliens sont gérés via le htaccess. Si vous le supprimez, les permaliens retrouvent leur structure par défaut. Et votre problème de réglage de permalien est tout à fait étrange.

    #2188209
    XtOf
    Participant
    Padawan WordPress
    50 contributions

    Merci pour votre réponse.

    Oups! Je constate que désormais je n’ai plus non plus accès à ma page d’accueil. Erreur 500 désormais. Peut-être que j’avais ma page d’accueil hier parce qu’elle était dans mon cache?

    Par rapport à votre message, je vais ajouter que chaque fois que je restaure une sauvegarde, je restaure également les fichiers htaccess qui optimisent la sécurité du site. Mais bon… d’habitude ça ne me pose pas de souci. Je ne vois pas pourquoi cette fois-ci cela m’empêcherait de faire fonctionner le site correctement. D’ailleurs, il me semble qu’ayant ajouté mes sauvegardes de fichiers htaccess, et ayant donc éventuellement écrasé ceux qui avaient été créés lors de l’installation, le site fonctionnait toujours correctement il me semble. Sauf qu’évidemment il ne contenait que l’article par défaut… Puis j’ai restauré les différentes tables de la base de données et à ce moment-là, ça ne fonctionnait plus.

    Vous dites que si on supprime le htaccess, les permaliens retrouvent leur structure par défaut. Je tente de supprimer le htacces à la racine du site pour voir…. Y a du mieux! Cette fois-ci, j’ai à nouveau ma page d’accueil. En revanche les autres pages sont inaccessibles.

    Du coup je tente de supprimer les htaccess situés dans les répertoires wp-admin, wp-content et wp-includes mais les pages internes sont toujours inaccessibles.

    Je remets pour l’instant mes htaccess en place. Pas envie d’avoir en plus des soucis de hacking…

    Est ce que quelqu’un verrait une piste?

    • Cette réponse a été modifiée le il y a 2 months et 1 week par  XtOf.
    • Cette réponse a été modifiée le il y a 2 months et 1 week par  XtOf.
    #2188241
    XtOf
    Participant
    Padawan WordPress
    50 contributions

    En attendant, je vais tenter une 3ème réinstallation, mais chez un autre hébergeur pour voir…

    #2189801
    XtOf
    Participant
    Padawan WordPress
    50 contributions

    Sur le forum, j’ai appris l’existence de l’extension Duplicator.

    Du coup, plutôt que de tenter la 3ème réinstallation manuelle sur un autre hébergeur, j’ai utilisé Duplicator. Et là, ça marche. En plus c’est plus simple qu’une migration manuelle. Que demande le peuple?

    #2189920
    XtOf
    Participant
    Padawan WordPress
    50 contributions

    En fait, Duplicator m’avait remis un htaccess de base, non sécurisé.

    Une fois que j’ai remis mon htaccess, celui de la racine (car j’en ai dans différents répertoires), erreur 500 à nouveau.

    En tâtonnant, j’ai réussi à identifier les lignes responsables de cela:

    AddOutputFilterByType DEFLATE text/html 
    AddOutputFilterByType DEFLATE text/plain 
    AddOutputFilterByType DEFLATE text/xml 
    AddOutputFilterByType DEFLATE text/css 
    AddOutputFilterByType DEFLATE text/javascript
    AddOutputFilterByType DEFLATE font/opentype
    AddOutputFilterByType DEFLATE application/rss+xml
    AddOutputFilterByType DEFLATE application/javascript
    AddOutputFilterByType DEFLATE application/json

    A la base, j’ai suivi des tutos pour optimises mes htaccess et renforcer la sécurité du site, dont certains fournis par Li-An je crois.

    Je les ai pas retrouvé, mais j’ai trouvé ceci: https://bloginfos.com/ameliorer-les-performances/

    Donc le code en question sert semble t il à activer la compression Gzip…

    Je suppose si désormais ça plante que j’avais la compression Gzip activée sur le précédent serveur mais plus sur le nouveau? Qu’est ce que vous en pensez?

     

    #2189924
    Li-An
    Modérateur
    Maître WordPress
    20215 contributions

    Ah non, ce n’est pas de moi ce code htaccess. Je n’ai d’ailleurs pas traité la sécurité mais juste l’optimisation via htaccess https://www.echodesplugins.li-an.fr/tutoriaux/90-sur-gmetrix-les-doigts-dans-le-nez/

    Je n’ai d’ailleurs croisé les lignes dont vous parlez. Ça a l’air assez exotique et pas compatible avec votre hébergeur visiblement.

    #2192066
    XtOf
    Participant
    Padawan WordPress
    50 contributions

    J’ai retrouvé le tuto dont je parlais… C’était celui-ci: https://www.iceranking.com/wordpress-seo/guide-complet-pour-nettoyer-et-securiser-wordpress-apres-un-hacking/

    Je me suis peut-être mal exprimé. Vous n’êtes peut-être pas l’auteur de cet article, mais vous me l’aviez conseillé à la suite d’un piratage. Du coup, comme il est mentionné de protéger son blog avec un htaccess, j’avais appliqué les conseils de cet article: https://wpmarmite.com/htaccess-wordpress/

    Du coup le code en question est le suivant et a donc comme je l’avais trouvé sur une autre source pour but d’activer la compression afin de rendre le site plus rapide semble-t-il:

    # Compressions des fichiers statiques
    <IfModule mod_deflate.c> 
        AddOutputFilterByType DEFLATE text/xhtml text/html text/plain text/xml text/javascript application/x-javascript text/css 
        BrowserMatch ^Mozilla/4 gzip-only-text/html 
        BrowserMatch ^Mozilla/4\.0[678] no-gzip 
        BrowserMatch \bMSIE !no-gzip !gzip-only-text/html 
        SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip dont-vary 
        Header append Vary User-Agent env=!dont-vary 
    </IfModule>  
    
    AddOutputFilterByType DEFLATE text/html  
    AddOutputFilterByType DEFLATE text/plain  
    AddOutputFilterByType DEFLATE text/xml  
    AddOutputFilterByType DEFLATE text/css  
    AddOutputFilterByType DEFLATE text/javascript
    AddOutputFilterByType DEFLATE font/opentype
    AddOutputFilterByType DEFLATE application/rss+xml
    AddOutputFilterByType DEFLATE application/javascript
    AddOutputFilterByType DEFLATE application/json  

    Encore faut-il pour rendre le site plus rapide que ce code soit accepté par l’hébergeur 🙂

    Je ferme le topic… Je ne pense pas qu’il y ait spécialement quelquechose à faire à part trouver un autre hébergeur qui accepte la compression gzip.

    #2192072
    Li-An
    Modérateur
    Maître WordPress
    20215 contributions

    Je vous ai donné le premier lien mais pas le second. Certains hébergeurs gèrent eux-mêmes cette compression alors vérifiez si ce n’est pas le cas du votre.

    #2192079
    XtOf
    Participant
    Padawan WordPress
    50 contributions

    Ok! Merci 🙂

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