Plantage màj 3.7.5 vers 3.8 : erreur 500 instantiation error

Réduire
X
 
  • Filtrer
  • Heure
  • Afficher
Tout effacer
nouveaux messages

  • [RÉGLÉ] Plantage màj 3.7.5 vers 3.8 : erreur 500 instantiation error

    Bonjour,

    Je vais assez rarement sur mon espace client chez mon hébergeur, mais aujourd'hui j'ai eu besoin d'y accéder pour créer le sous-domaine sur lequel je vais (enfin !) tenter à nouveau la mise à jour vers Joomla! 3.8 (sachant que je suis encore en 3.7.1 depuis que mon site a totalement planté quand j'ai tenté la 3.8.2, cette fois je compte y aller par petits pas successifs plutôt que sauter autant de versions d'un coup. j'espère que je ne fais pas une erreur de ce point de vue).
    Bref. Là n'est pas mon propos.

    Donc :

    1) en visitant mon espace client, je constate l'apparition d'une nouvelle fonctionnalité, dénommée 'Niveau de performance'.
    Je clique dessus et constate que je suis, par défaut, sur le niveau de performance 3, mais que mon hébergeur me propose d'upgrader cela de la façon suivante :

    NIVEAU RAM MAX. PROCESSUS MÉMOIRE LIMITE PRIX PAR MOIS
    Niveau de performance 1 2,5 Go 300 / min 512 Mo —
    Niveau de performance 2 6 Go 300 / min 640 Mo —
    Niveau de performance 3 9 Go 900 / min 640 Mo 0 €
    (activé)
    Niveau de performance 4 15 Go 1200 / min 768 Mo 1,99 €
    (recommandé)
    Niveau de performance 5 19 Go 1500 / min 768 Mo 3,99 €

    C'est là que j'ai besoin de votre œil d'expert-e.
    Quel impact sur la vitesse du site peut avoir le passage d'un niveau 3 à un niveau 4 voire 5 ?

    2) en consultant mon panneau Aesecure, je vois aussi que je suis toujours en php 5.6, alors que mon hébergeur propose php 7.0 7.1 et 7.2 (en recommandant la 7.1)
    Quand je lis des articles sur le changement de version PHP, je me fais un peu flipper sur de possibles risques d'incompatibilité, mais sans bien comprendre ce que je lis (trop tech pour moi).
    Qu'est-ce que je risque à changer de version PHP ?
    Et est-il possible de revenir en arrière si quelque chose plante ?

    Pardon pour la probable naïveté de mes questions, n'oubliez pas que je suis une amateure

    Merci d'avance pour vos lumières
    Bon week-end à rallonge,
    Flo
    --

    EDIT 21h29 : vu comment la conversation a dérivé de son sujet initial, je rebaptise mon sujet pour qu'il reflète la réalité des échanges
    Dernière édition par FlodAriege à 02/04/2018, 20h31 Raison: changement de sujet au fil de la conversation
    Flo, Ariège

    Il n'y a que celui qui a honte d'apprendre qui a peur de demander

  • #2
    Bonjour,

    Je découvre grâce à toi cette nouvelle proposition de 1&1.
    Je n'ai a priori pas d'idée sur l'intérêt d'un tel upgrade, tout dépendant surtout de l'importance de la fréquentation et de la sollicitation de mémoire.
    Sur mon serveur PHPNET, j'atteins, avec mes sites pro, perso et de test (tous peu visités, c'est vrai, mais plus de 20 en tout) une moyenne de consommation mémoire inférieure à 1 Go.
    Sur le même serveur d'un client avec une boutique VM et 7 autres sites Joomla! la RAM tourne aux environs de 1 Go aussi.

    En utilisant un système de cache et une extension permettant d'utiliser la compression, ça peut éventuellement suffire.
    Gzip est bien disponible chez 1&1, en tout cas sur les serveurs où j'ai vérifié, mais Joomla! n'arrive pas à l'activer. aeSecure Premium oui, d'autres peut-être aussi.

    Pour tes mises à jour, active le plugin "Sauvegarde avant mise à jour" d'Akeeba s'il ne l'est pas encore, récupère les patchs de mise à jour pour chaque étape de la 3.7.1 à la 3.7.5 : à chaque installation, tu auras une sauvegarde avant chaque mise à jour, donc la possibilité de la restaurer en cas d'incident, sans devoir revenir à la 3.7.1
    Une fois en 3.7.5, on est devant un gros problème : pas de patch 3.7 vers 3.8 mais le même pour passer de toutes les versions de 2.5 à 3.7 vers la 3.8 donc réinstallation de tas de fichiers déjà présents et de modifications de tables déjà faites.

    Complément : je viens de regarder mon serveur et j'ai une question : que dit la page d'analyse de performances sur ton panel d'administration ?
    Dernière édition par RobertG à 01/04/2018, 17h49
    "Patience et longueur de temps font plus que force ni que rage..." (La Fontaine : Le Lion et le Rat) - "Il n'y a pas de problèmes; il n'y a que des solutions" (André Gide).
    MoovJla et LazyDbBackup sur www.joomxtensions.com - FaQ sur www.fontanil.info - Site pro : www.robertg-conseil.fr chez PHPNET, sites perso chez PlanetHoster + sites gérés chez PHPNET, PlanetHoster, Ionos et OVH

    Commentaire


    • #3
      Envoyé par RobertG Voir le message

      Complément : je viens de regarder mon serveur et j'ai une question : que dit la page d'analyse de performances sur ton panel d'administration ?
      C'est-à-dire ?
      Si tu parles du graphique en barres qui s'affiche sur la page Niveau de performance de 1&1, alors : toutes les barres sont au vert, avec des valeurs à 100% (sauf un jour à 99%)
      C'était ça ta question ?

      Pour gzip, je suis un peu perplexe, car tout ceux qui ont mis le nez dans ma config m'ont toujours dit que 1&1 ne l'acceptait pas. Mais il faut que je précise que je suis sur un serveur mutualisé avec un hébergement 1&1 Unlimited Pro.
      J'ai Aesecure Premium+
      ... donc je pourrais peut-être parvenir à optimiser mon site ?
      Tu me fais rêver là.

      Pour les mises à jour, c'est bien mon intention : passer de version en version sans faire de saut d'étapes.
      à suivre...

      Et pour PHP, qu'en penses-tu ?
      Flo, Ariège

      Il n'y a que celui qui a honte d'apprendre qui a peur de demander

      Commentaire


      • #4
        Oui, c'était ça ma question. Donc globalement, la puissance de ton serveur est suffisante.
        J'ai un Unlimited pour tests, avec niveau 2 de performances.

        Ceux qui ont mis le nez dans ta config n'ont pas cherché dans l'onglet "PHP" des infos système et cherché "gzip" ?
        Avec aeSecure, active les points 8.1 et 8.2 s'ils ne le sont pas déjà et vérifie avec GTmetrix par exemple si Gzip est toujours considéré comme absent ou pas.
        Le site d'une cliente : "Enable gzip compression A (100) AVG SCORE: 84%" Le score est à 100%, ce qui veut dire que Gzip est bien activé et ses scores GTmérix sont de 98% pour PageSpeed et 86% pour YSlow.

        Pour PHP, tu peux rester en 5.6 dans un premier temps puis passer en 7.0 avant de mettre à jour de 3.7 à 3.8
        "Patience et longueur de temps font plus que force ni que rage..." (La Fontaine : Le Lion et le Rat) - "Il n'y a pas de problèmes; il n'y a que des solutions" (André Gide).
        MoovJla et LazyDbBackup sur www.joomxtensions.com - FaQ sur www.fontanil.info - Site pro : www.robertg-conseil.fr chez PHPNET, sites perso chez PlanetHoster + sites gérés chez PHPNET, PlanetHoster, Ionos et OVH

        Commentaire


        • #5
          bon ben pour l'instant, ma restauration de sauvegarde a planté sur une erreur 500, donc je verrai ça demain (le temps que je uploade de nouveau une sauvegarde, il y en a pour 2 plombes vu ma connexion ici)
          la page d'accueil s'affichait nickel, mais aucun des liens ne fonctionnaient.
          j'ai tout viré et je recommence demain.
          Flo, Ariège

          Il n'y a que celui qui a honte d'apprendre qui a peur de demander

          Commentaire


          • #6
            Envoyé par FlodAriege Voir le message
            la page d'accueil s'affichait nickel, mais aucun des liens ne fonctionnaient.
            C'est souvent du au fichier htaccess qu'il faut juste désactiver
            FlodAriege aime ceci.
            Ce forum, vous l'aimez ? il vous a sauvé la vie ? Vous y apprenez chaque jour ? Alors adhérez à l'AFUJ https://www.joomla.fr/association/adherer
            Cette année, le JoomlaDay FR a lieu à Bruxelles, les 20 et 21 mai 2022, plus d'infos et inscriptions : www.joomladay.fr

            Commentaire


            • #7

              Bonjour,

              A mon avis, tu n'iras pas plus vite en augmentant le niveau sauf à mettre le prix. En terme de comparaison, on peut aller jusqu'à 5 fois plus rapidement que ta configuration actuelle pour des hebergements équivalent à 3 euro par mois. L'essentiel, c'est de trouver le juste milieu entre les besoins, la performance réelle, l'optimisation et la compatibilité.

              A lire le détail de leur propositions, elles sont un peu plus adaptées qu'avant. Mais ayant fait l’expérience à plusieurs reprises, j'arrive à des performances extraordinaires rien qu'en utilisant 2go de memoire et un processeur atom. Donc le plus petit des dédiés bien configurés sur online ou ovh pourrait fort bien dépasser toute ces configurations si on est à moins de 100 visites par jour (techniquement, il y a un moment où l'optimisation a aussi ses limites ).

              1&1 se situe donc parmi les hébergeurs low-cost mutualisé. Des offres basses mais pas tant que ça avec de l'espace illimité (dès que l'on met un peu plus que l'offre basic). Quand on parle d'illimité, c'est surtout qu'il déduise que tu ne servira pas comme espace de stockage vu que c'est contraire à leur règlement (noté dans leur conditions), evidemment ils sont toujours gagnants. Le partenariat avec cloudflare leur permet d'ajouter un cdn gratuit et le système railgun suivant la configuration qui permet de booster les sites.
              source : http://newsroom.1and1.fr/2017/03/28/...ormance/#_ftn1

              A toi de voir la stratégie à adopter, entre rester comme ça, changer de niveau ou d'hébergeur mais je crois bien que la priorité c'est de passer en dernière version de joomla et en php 7. Apparemment tu pourrais activer le cache opcode de php7 et d'autres facteurs de performance : https://community.1and1.com/php-7/

              fichier php.ini à la racine de ta config 1&1

              Code:
              zend_extension=opcache.so;
              opcache.enable=1;opcache.memory_consumption=32;
              opcache.interned_strings_buffer=8;
              opcache.max_accelerated_files=3000;
              opcache.revalidate_freq=180;
              opcache.fast_shutdown=0;
              opcache.enable_cli=0;
              opcache.revalidate_path=0;
              opcache.validate_timestamps=2;
              opcache.max_file_size=0;
              opcache.file_cache= .../homepages/tonchemin/htdocs/.opcache;
              opcache.file_cache_only=1;
              Perso, je choisirai une offre incluant le cdn si cela ne dépasse pas ton budget.

              Je considère 1&1 comme un hébergement stable (mieux que d'autres mutu) mais pas forcement performant, du moins pas il n'est pas dans les premiers de ma liste.
              Aujourd'hui, je tiens compte d'autres paramètres comme des disques dur ssd, un cache performant, une puissance et bande passante adaptée à la fréquentation.
              Le prix est à prendre en compte uniquement avec la configuration dans sa globalité (ce qui inclus également la réactivité du support).

              En résumé oui pour l'évolution mais je te conseille php7 en premier, le reste suivra (tu as le temps). Le dernier conseil serait de desactiver aesecure et ses modifications dans le htaccess, jchoptimize et autres extensions le temps des mises à jour. S'assurer de la compatibilité du template en n'oubliant pas d'afficher les erreurs afin de corriger les problèmes préalables (vérifier également la console du navigateur).

              Voila, si cela peut te faire avancer sur tes décisions, sache que je peux te partager le paramétrage avec cloudflare (le cdn) si tu l'utilise à l'avenir

              Yann
              FlodAriege aime ceci.
              Joomla User Group (JUG) Lille : https://www.facebook.com/groups/JUGLille/

              Commentaire


              • #8
                Envoyé par manu93fr Voir le message
                C'est souvent du au fichier htaccess qu'il faut juste désactiver
                Salut,
                J'ai viré le .htaccess, et maintenant je n'ai plus d'erreur 500 mais... des erreurs 404

                Je réactive aesecure, et là je reviens à des erreurs 500.

                Rappel: ma sauvegarde est sur un sous-domaine (bon sang ! pourtant je l'ai déjà fait, et je n'ai pas eu ce problème à l'époque...)

                qu'est-ce que j'oublie ??

                EDIT : j'ai bidouillé le .htaccess que j'ai sur mon site en production en modifiant le nom du dossier dans lequel le sous-domaine est installé et en ajoutant le sous-domaine à l'adresse du site et il semblerait que ça fonctionne :
                Là où c'était écrit :

                RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?vieuxdossier\.monsite\.fr [NC]

                J'ai rectifié ainsi :

                RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?nouveaudossier\sousdomaine.monsite\.fr [NC]

                Plus d'erreur 500 ni 404.

                Nouveau problème : tout le monde me dit de désactiver le htaccess pour faire les mises à jour.
                Mais quand je le désactive plus rien ne fonctionne.
                Comment faire ???????????
                Dernière édition par FlodAriege à 02/04/2018, 13h07
                Flo, Ariège

                Il n'y a que celui qui a honte d'apprendre qui a peur de demander

                Commentaire


                • #9
                  Envoyé par FlodAriege Voir le message

                  Nouveau problème : tout le monde me dit de désactiver le htaccess pour faire les mises à jour.
                  Mais quand je le désactive plus rien ne fonctionne.
                  Il ne faut pas desactiver le fichier htaccess car ton site a besoin de la réécriture et de certains paramètres.
                  Seulement, entre la version htaccess de base livré avec joomla et celle que tu utilise, il y a certainement beaucoup plus de paramètres
                  d'où les problèmes rencontrés...

                  Le mieux serait d'avoir un htaccess avec le strict nécessaire pour les maj et de l'autre la version super-optimisé avec tes modifs, aesecure, jch, etc...

                  Comme je te l'ai dit, desactive également les extensions et éléments d'optimisation, compression, minification puis reactive après avoir effectué les mises à jour
                  et vérifie qu'il n'y a pas d'erreur (avant et après) en affichant le rapport (mode dev) via la configuration du site ainsi que dans la console du navigateur (avant et après).

                  Si tu as des déjà des erreurs dans ton site, le fait de mettre à jour ne va pas arranger les choses. Il faut traiter les problèmes avant...
                  C'est mon avis et c'est ce que je fait habituellement sur les "vieux" sites.

                  Yann

                  ps: pour info, tu as aussi une erreur dans la console du navigateur sur les fichiers compressé par jch.

                  FlodAriege aime ceci.
                  Joomla User Group (JUG) Lille : https://www.facebook.com/groups/JUGLille/

                  Commentaire


                  • #10
                    Envoyé par daneel Voir le message
                    Il ne faut pas desactiver le fichier htaccess car ton site a besoin de la réécriture et de certains paramètres.
                    Seulement, entre la version htaccess de base livré avec joomla et celle que tu utilise, il y a certainement beaucoup plus de paramètres
                    d'où les problèmes rencontrés...

                    Le mieux serait d'avoir un htaccess avec le strict nécessaire pour les maj et de l'autre la version super-optimisé avec tes modifs, aesecure, jch, etc...
                    Oui, j'ai vu ça mais... tu es bien placé pour savoir que j'ai un .htaccess qui n'est pas sorti de mon brillant esprit lol mais de celui des contributeurs ici, à commencer par toi.
                    D'où mon immense difficulté à repérer dans ce code ce qui est indispensable au bon fonctionnement de ce qui relève de la "simple" optimisation...
                    J'ai bien tenté avec le htaccess par défaut, mais sans succès.
                    Là je me heurte de plein fouet à mon incompétence.

                    Envoyé par daneel Voir le message
                    Comme je te l'ai dit, desactive également les extensions et éléments d'optimisation, compression, minification puis reactive après avoir effectué les mises à jour
                    et vérifie qu'il n'y a pas d'erreur (avant et après) en affichant le rapport (mode dev) via la configuration du site ainsi que dans la console du navigateur (avant et après).
                    J'ai tenté de désactiver Aesecure mais ça faisait tout planter (problème du htaccess j'imagine).
                    J'ai désactivé JCH.
                    ... à part ça je ne vois pas ce que je peux désactiver de plus (aucune option de compression ou minification n'étant activée dans mon template par exemple)
                    J'ai réglé de rapport d'erreur à "développement"
                    J'ai passé le cache de "conservateur" à "désactivé"

                    Envoyé par daneel Voir le message
                    Si tu as des déjà des erreurs dans ton site, le fait de mettre à jour ne va pas arranger les choses. Il faut traiter les problèmes avant...
                    C'est mon avis et c'est ce que je fait habituellement sur les "vieux" sites.
                    Les seules erreurs qui s'affichent depuis que j'ai passé le rapport d'erreur à "développement", c'est :

                    Notice: Undefined property: stdClass::$facebookmeta_fbuserprofile in /homepages/7/***/htdocs/***/plugins/system/socialmeta/socialmeta.php on line 762
                    Notice: Undefined property: stdClass::$facebookmeta_twitteruser in /homepages/7/***/htdocs/***/plugins/system/socialmeta/socialmeta.php on line 790
                    Je crois me souvenir qu'il s'agit d'un petit problème avec flexicontent, mais sans réelle importance (tellement peu qu'elle n'est pas sur la liste de leurs priorités)

                    Et, en bas d'écran :
                    Only variables should be assigned by reference in /homepages/7/***/htdocs/***/modules/mod_cookiesaccept/mod_cookiesaccept.php on line 24

                    Tu dois connaître Cookies Accept, inutile que je t'explique de quoi il s'agit. Je n'ai pas le sentiment que cette erreur soit bien grave, non ?

                    Envoyé par daneel Voir le message
                    ps: pour info, tu as aussi une erreur dans la console du navigateur sur les fichiers compressé par jch.
                    Merci pour ce signalement.
                    Je viens d'ouvrir un ticket chez JCH, j'espère qu'il pourra m'aider... parce que pour moi ces messages d'erreur c'est du chinois...


                    Donc, si je résume :
                    A ce stade j'ai bien l'impression que mon plus gros problème, c'est cette histoire de htaccess.
                    Tant que je ne pourrai pas en implanter un assez basique pour ne pas créer de problème, mais contenant les instructions minimum pour permettre le fonctionnement, je risque fort de voir mes mises à jour planter...
                    je suis un peu (... beaucoup...) découragée, là.
                    Je ne sais même pas si ça vaut le coup que j'essaie de faire ces mises à jour...
                    Dernière édition par FlodAriege à 02/04/2018, 14h19
                    Flo, Ariège

                    Il n'y a que celui qui a honte d'apprendre qui a peur de demander

                    Commentaire


                    • #11
                      ok ok

                      pourquoi ne pas essayer de mettre ce htaccess de coté et de récuperer celui livré avec le code original.
                      en ajoutant uniquement tes spécifités comme le www, le sous-repertoire et redirection https...

                      RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?nouveaudossier\sousdomaine.monsite\.fr [NC]
                      RewriteRule ....

                      attention, je crois que ta version actuelle ne fonctionne qu'en php 5.6 donc la bascule php 7 sera faite après les
                      mises à jour joomla & extension (il faut confirmer que le template soit également compatible php 7 ).

                      Je n'ai pas beaucoup de temps aujourd'hui mais dans la semaine on pourra revoir le htaccess au complet
                      pour clôturer cet épisode... pour maintenant, cela peut attendre 2-3 jours
                      Dernière édition par daneel à 02/04/2018, 15h11
                      FlodAriege aime ceci.
                      Joomla User Group (JUG) Lille : https://www.facebook.com/groups/JUGLille/

                      Commentaire


                      • #12
                        Salut,
                        J'ai viré le .htaccess, et maintenant je n'ai plus d'erreur 500 mais... des erreurs 404
                        Oui parce qu'il faut dans le meme temps remettre le paramètre de réécrituve au vol des urls sur NON

                        Je ne savais pas que tu avais un htaccess "blindé" ... je suis du meme avis que Daneel, si tu en remets un en place sur le site de test pour ta mise a jour, remets celui de Joomla! par defaut pour évité les effets de bord et désactive tous les plugin d'optimisation
                        FlodAriege aime ceci.
                        Ce forum, vous l'aimez ? il vous a sauvé la vie ? Vous y apprenez chaque jour ? Alors adhérez à l'AFUJ https://www.joomla.fr/association/adherer
                        Cette année, le JoomlaDay FR a lieu à Bruxelles, les 20 et 21 mai 2022, plus d'infos et inscriptions : www.joomladay.fr

                        Commentaire


                        • #13
                          C'est un point en effet auquel on ne pense pas lorsqu'on restaure ailleurs un site où JCH Optimize est utilisé : son cache.
                          J'en ai parlé dans une autre discussion, sur certains sites (je n'ai pas réussi à savoir pourquoi), JCH utilise un dossier cache dans "media/plg_jchoptimize" que la sauvegarde Akeeba embarque, nécessitant de désactiver JCH après restauration, ou de penser à exclure le contenu du dossier dans les paramètres du profil Akeeba.

                          Dans la procédure de restauration, Akeeba propose (par défaut ?) de restaurer le .htaccess d'origine, et là, chez 1&1, il ne faut pas oublier ensuite de décommenter la ligne "RewriteBase" pour éviter cette erreur 500.
                          "Patience et longueur de temps font plus que force ni que rage..." (La Fontaine : Le Lion et le Rat) - "Il n'y a pas de problèmes; il n'y a que des solutions" (André Gide).
                          MoovJla et LazyDbBackup sur www.joomxtensions.com - FaQ sur www.fontanil.info - Site pro : www.robertg-conseil.fr chez PHPNET, sites perso chez PlanetHoster + sites gérés chez PHPNET, PlanetHoster, Ionos et OVH

                          Commentaire


                          • #14
                            Envoyé par daneel Voir le message
                            ok ok

                            pourquoi ne pas essayer de mettre ce htaccess de coté et de récuperer celui livré avec le code original.
                            en ajoutant uniquement tes spécifités comme le www, le sous-repertoire et redirection https...

                            RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?nouveaudossier\sousdomaine.monsite\.fr [NC]
                            RewriteRule ....
                            Je suis en train d'essayer de repérer les lignes indispensables, toutes celles qui sont en lien avec REWRITE

                            Envoyé par daneel Voir le message
                            attention, je crois que ta version actuelle ne fonctionne qu'en php 5.6 donc la bascule php 7 sera faite après les
                            mises à jour joomla & extension (il faut confirmer que le template soit également compatible php 7 ).
                            juste avant de lancer la màj vers 3.8, je viens de basculer en php 7.1:
                            a a fait planter pas mal de choses, et notamment mon megamenu qui n'a pas l'air d'apprécier.
                            j'ai descendu d'un cran à php 7.0 : tout est rentré dans l'ordre

                            (quand j'étais en 7.1 j'ai vu un message d'erreur relatif à tooltip gc, que je n'utilise plus et que j'ai donc désinstallé)

                            Envoyé par daneel Voir le message
                            Je n'ai pas beaucoup de temps aujourd'hui mais dans la semaine on pourra revoir le htaccess au complet
                            pour clôturer cet épisode... pour maintenant, cela peut attendre 2-3 jours
                            Merci de ta proposition, c'est vraiment sympa de ta part.
                            je vais faire de mon mieux pour ne pas avoir besoin de t'embêter, mais si je plante vraiment, je reviens vers toi pour ne pas me noyer
                            Flo, Ariège

                            Il n'y a que celui qui a honte d'apprendre qui a peur de demander

                            Commentaire


                            • #15
                              Envoyé par RobertG Voir le message
                              C'est un point en effet auquel on ne pense pas lorsqu'on restaure ailleurs un site où JCH Optimize est utilisé : son cache.
                              J'en ai parlé dans une autre discussion, sur certains sites (je n'ai pas réussi à savoir pourquoi), JCH utilise un dossier cache dans "media/plg_jchoptimize" que la sauvegarde Akeeba embarque, nécessitant de désactiver JCH après restauration, ou de penser à exclure le contenu du dossier dans les paramètres du profil Akeeba.
                              ... et crois-tu que je puisse simplement tenter de supprimer ce dossier (ou son contenu) ?

                              (Là on parle (je le dis surtout pour moi) du site en production, qui est issu de la restauration d'une sauvegarde après le gros plantage de ma dernière tentative de màj vers j!3.8
                              Donc ce que tu dis s'applique plein pot à mon cas de figure.)

                              Envoyé par RobertG Voir le message
                              Dans la procédure de restauration, Akeeba propose (par défaut ?) de restaurer le .htaccess d'origine, et là, chez 1&1, il ne faut pas oublier ensuite de décommenter la ligne "RewriteBase" pour éviter cette erreur 500.
                              C'est exact, je me souviens bien avoir vu une case cochée par défaut dans la procédure de restauration Akeeba avec restauration du htaccess par défaut.
                              Ne sachant pas trop ce qui provoquait l'erreur 500, j'ai carrément remis le htaccess de mon site en production en modifiant ce qui avait besoin de l'être (puisque le sous-domaine sur lequel je tente les mises à jour est sur un dossier différent de celui du site en production).
                              Si je te comprends bien, et ça rejoint ce que dit Daneel, il m'aurait suffi de remettre en fonction les lignes Rewrite en les décommentant.

                              NB: j'ai depuis (2014 je crois) une ligne 1&1 Hack ainsi rédigée dans mon htaccess :
                              # 1&1 Hack
                              RewriteRule !index\.php - [C]
                              RewriteRule ^ /index.php

                              Je ne sais pas si elle est toujours utile.
                              A vrai dire j'ai l'impression d'avoir des lignes en double dans mon htaccess : il faudrait que je lance une analyse (je ne sais pas trop avec quel outil, peut-être excel avec mise en forme conditionnelle des doublons)

                              PS : je suis en train d'envoyer les fichiers et dossiers de la 3.8 vers mon serveur. C'est long, il doit effectivement y avoir un paquet de fichiers là dedans (comme tu me le disais plus haut dans ce post). je croise les doigts très fort : si ça plante ma 1ère tentative de correction portera sur le htaccess. Sinon je pourrai toujours restaurer la sauvegarde 3.7.5, dernière version à laquelle je suis arrivée sans souci.
                              Flo, Ariège

                              Il n'y a que celui qui a honte d'apprendre qui a peur de demander

                              Commentaire

                              Annonce

                              Réduire
                              Aucune annonce pour le moment.

                              Partenaire de l'association

                              Réduire

                              Hébergeur Web PlanetHoster
                              Travaille ...
                              X