Htaccess régénéré un peu vite

Bonjour,

Je crois que j'ai trouvé un petit caillou dans l'engrenage (voir cette discussion). Je transmets mes observations, et je vous laisse juge. :)

Très simplement, j'ai tenté d'activé la compression GZIP. Ça n'a pas fonctionné, certainement du fait de mon hébergeur associatif Lautre.net. Déjà que pour la réécriture d'URL il a fallu bidouiller (voir ici), je ne suis donc pas étonné. Bref. Le problème s'est posé quand il a fallu rétablir la situation. Après avoir remis le paramètre adéquat à 0 dans parametres.xml, je me suis aperçu que mon htaccess avait été complètement régénéré.

C'est peut-être normal (et même sûrement). Sauf que, et je crois que je ne suis pas le seul, mon htaccess avait été longuement peaufiné à la main. J'ai donc tout perdu. Honte à moi, il m'aurait suffit d'en faire une copie en amont. Certes. Je trouve quand même un peu violent qu'un tel fichier, qu'un webmaster peut être amené à manipuler assez fréquemment, se retrouve sans prévenir écrasé. Pourquoi le script ne pourrait-il pas prévenir/sauver ?

Voilà pour ce petit retour d'expérience,
Sinon, tout roule, merci Pluxml, tu es un outil formidable. :)

Réponses

  • StéphaneStéphane Member, Former PluXml Project Manager
    Bonjour
    La compression gzip et le fichier htaccess sont 2 choses différentes. Mettre ou enlever la compression gzip n'intervient en rien sur la présence ou non du fichier htaccess. Donc si tu avais un problème après avoir remis le paramètre à 0 dans parametres.xml et que tu avais un souci avec ton htaccess cela n'a absolument rien à voir et ce n'est pas lié.
    Dans l'admin il n'y a que le paramètre "réécriture d'url" qui génère le htaccess avec un message visible à l'écran si le fichier existe déjà et qu'il sera écrasé si l'option est activée.
    Tout est donc prévu, sauf les bidouilles ou les erreurs de manips qui sont très (trop) souvent à l'origine de nombreux autres problèmes non maitrisés.

    Consultant PluXml

    Ancien responsable du projet (2010 à 2018)

  • Bonjour Stéphane et merci pour ta réponse,

    J'entends bien que l'option de compression GZIP et le htaccess sont deux choses différentes. J'entends bien aussi qu'il n'y a aucune raison que l'activation du paramètre GZIP modifie le htaccess. Tout ceci fait sens.

    Alors, parce qu'il ne me semble pas avoir bidouillé, je réessaye la manipulation pour comprendre ce qui est parti de travers chez moi :
    * mon site fonctionne bien ;
    * je me rends dans la partie administration, je coche la case compression GZIP et je valide.
    * j'obtiens directement une erreur interne au serveur 500.
    * je vérifie mon htaccess par ftp : il a été écrasé (cette fois, j'en avais fait une copie, ouf).
    Je ne sais pas comment, ni pourquoi, mais le fait d'activer la compression a bien engendré un nouveau htaccess.

    Faisons l'hypothèse qu'à ce moment, c'est la réécriture d'URL qui foire tout, faisant porter le chapeau à la compression GZIP.
    * mon site est toujours down ;
    * dans parametres.xml je bascule "gzip" à 0 ;
    * mon site est encore et toujours down ;
    * dans parametres.xml je bascule cette fois le paramètre "urlrewriting" à 0 ;
    * mon site est toujours down ;
    * je supprime le htaccess sur le serveur ;
    * mon site revient.
    Mon problème de site down n'est donc pas un problème d'option activée ou non, mais seulement un problème de htaccess défaillant.

    Mais ça ne nous dit rien sur la raison pour laquelle mon htaccess est subitement devenu défaillant. Réessayons.
    À ce moment, je n'ai donc plus de htaccess du tout à la racine du site.
    * mon site fonctionne ;
    * j'active dans la partie administration l'option compression GZIP ;
    * mon site résiste : pas d'erreur 500 ;
    * je vérifie via ftp : un htaccess vierge a été créé.
    * je supprime ce htaccess ;
    * je désactive l'option gzip ;
    * je vérifie via ftp : un htaccess à nouveau été crée

    Conclusion, même avec l'urlrewriting désactivée, je ne sais ni pourquoi ni comment, mais intervenir sur cette option de compression, dans un sens ou dans l'autre, régénère le htaccess. Si la compression GZIP et le htaccess sont deux choses différentes, alors ce n'est pas un fonctionnement normal, si ?

    Pour information supplémentaire, tout marche bien si j'effectue les opérations dans cet ordre :
    * mon site fonctionne :
    * je désactive l'url rewriting : le htaccess reste présent mais est devenu vierge,
    * j'active la compression GZIP ;
    * je réactive l'url rewriting ;
    * mon site fonctionne toujours (à condition d'avoir manuellement sauvegardé et restauré l'ancien htaccess pour éviter l'erreur 500)
  • StéphaneStéphane Member, Former PluXml Project Manager
    Merci pour toutes ces explications. Je vais faire une serie de test pour essayer de recouper avec tout ce que tu as écris et de trouver l'origine du problème. Je reviens vers toi dès que j'ai des élements à te fournir.

    Consultant PluXml

    Ancien responsable du projet (2010 à 2018)

  • StéphaneStéphane Member, Former PluXml Project Manager
    Origine du problème localisée.

    Donc pour faire simple et court, du moment que l'on clique sur le bouton "Modifier la configuration avancée" sur l'écran Paramètres > Configuration avancée, le fichier .htaccess est modifiée. Donc absolument rien à voir avec la compression gzip.

    Donc encore merci d'avoir pris le temps d'avoir rédiger tes explications.

    edit: j'ai raccourci mon explication pour faire plus simple :p

    Consultant PluXml

    Ancien responsable du projet (2010 à 2018)

  • StéphaneStéphane Member, Former PluXml Project Manager
    Pour info: issue #25

    Consultant PluXml

    Ancien responsable du projet (2010 à 2018)

  • Bon, je n'ai pas tous compris, mais peu importe, j'ai mon workaround. Mais dans l'idée oui, on devrait pouvoir désactiver la réécriture temporairement, sans que cela affecte la configuration du htaccess, même personnalisé à la main.

    Je suis ravi d'avoir fait (un poil) avancer le schmilblick.

    Merci surtout à toi pour ton écoute et ta réactivité ! :)
Connectez-vous ou Inscrivez-vous pour répondre.