erreur 500 et pages vierges

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

  • erreur 500 et pages vierges

    Bonjour,
    J'ai un souci depuis hier : j'ai mis mon site J3.8 à jour avec l'archive de mise à jour J4 téléchargée sur le site J. Le back end m'a renvoyé une erreur 500.
    J'ai commencé à chercher des solutions sur les forums et je me suis aperçu que j'avais une erreur inédite : mon site (à partir du index.php, j'ai un index.html juste "avant" qui fonctionne bien) et mon administration renvoient des pages blanches :
    L'accueil en .html

    L'accueil en php

    L'accueil admin

    Le problème étant que je n'ai plus accès à mon admin.
    Je suppose que le souci provient des tables mais je suis totalement ignorant, je suis juste démuni.
    Non, je n'ai pas appliqué les précautions d'usage avant la mise à jour, ça n'a jamais empêché de mettre à jour tous mes sites depuis dix ans et là... il suffit d'une fois
    Si quelqu'un avait des pistes pour tenter de régler le problème...
    Merci,
    C

  • #2
    Bonjour,

    C’est l’occasion de refaire le site à neuf avec J4
    et ensuite de créer régulièrement des copies de sécurités avec Akeeba.

    Commentaire


    • #3
      Certes mais, comment récupérer mes articles dans l'état où ils étaient avant la manipulation d'idiot ?

      Commentaire


      • #4
        Bonjour,

        Tout d'abord, on ne se lance pas dans une telle migration sans avoir d'abord cherché des informations sur la procédure, surtout si on utilise une version ancienne de Joomla! (3.8, tu as écrit, et la migration nécessite d'être d'abord en 3.10), ensuite il est indispensable comme l'a écrit Helloo de faire une sauvegarde.

        Si donc ni toi ni ton hébergeur n'avez de sauvegarde, la seule solution pour récupérer tes articles sera de récupérer une copie de ta base de données et de travailler avec phpMyAdmin sur un serveur local pour y récupérer, dans la table #__content, les titres et contenus des articles pour les coller dans de nouveaux articles d'une version 4.

        Par ailleurs, compte tenu des difficultés qui ont été signalées ici avec Free, je ne suis pas sûr, si ton site y était hébergé, tu puisses y installer une version 4 de Joomla!
        "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
          Bonjour Robert,
          Merci pour ces précisions. Je me suis trompé, j'étais bien en J3.10
          Pour les précautions, je sais bien, comme je l'ai précisé, ça n'a jamais posé de problème...
          J'ai une sauvegarde du site (ftp) mais les articles sont bien dans la SQL, non ?
          Quant à Free, c'est l'hébergeur du site sur lequel j'ai mis les photos, pas celui qui héberge le site sur lequel j'ai Joomla. Ce dernier est hébergé par OVH.
          Si je comprends bien, il "suffit" de récupérer la table #content sur la base, tout supprimer, vider la base, réinstaller J4 et coller la table #content dans la base ?

          Commentaire


          • #6
            Bien, si tu es chez OVH, tu peux utiliser ton Manager pour restaurer les fichiers puis la base en le faisant sur des versions datant du même jour de préférence, avant ta manipulation.
            Donc si tu as fait cette tentative de migration ce matin, tu dois avoir une sauvegarde de ce week-end qui te permette d'avoir les deux parties datant d'à peu près du même moment.
            Je ne sais pas comment fonctionne au juste la restauration d'OVH, si c'est le contenu complet du serveur qui est vidé ou seulement les fichiers écrasés, mais je te conseille quand même avant restauration de vider le dossier du site pour éviter tout risque de mélange de fichiers des deux versions.

            Cela dit, installe et utilise Akeeba backup régulièrement, la restauration sera plus facile en cas d'incident.
            "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


            • #7
              D'accord, je vais tenter ça.
              Merci beaucoup.
              Je reviendrai pleurer ou fermer le sujet une fois le résultat constaté
              Pour Akeeba, c'est noté depuis longtemps mais, clairement, j'ai procrastiné une fois de trop...

              Commentaire


              • #8
                Bonjour,
                Depuis mon dernier message, j'ai uploadé la sauvegarde des fichiers par l'interface OVH, à plusieurs reprises (plusieurs dates), ça ne change rien, j'ai toujours mes pages index.php vierges.
                J'ai aussi essayé de reuploader mes propres fichiers depuis mon client ftp, ça n'a rien changé non plus.
                J'ai modifié la déclaration des tables du config.php (je n'y connais rien, j'ai juste trouvé cette ligne-là), je ne sais pas si c'est suffisant pour changer quoi que ce soit, ça n'a rien changé non plus.
                Finalement, j'ai tout supprimé (fichiers, ftp), j'ai réinstallé un Joomla 3.10.2 mais, quand je déclare les tables de la date du bug, je n'ai rien (pages vierges). Quand je reinstalle un J3.10.2 et que je créé de nouvelles tables, tout fonctionne : http://www.inbadreams.com/
                Forcément, comme ça, ça fonctionne.
                Une install de Joomla ne touche pas aux tables sql ? Si c'est le cas, c'est forcément un problème de déclaration quelconque du ovhconfig, htaccess ou du config.php non ?
                Est-ce que c'est toi John Wayne, ou est-ce que c'est moi ?

                Commentaire


                • #9
                  Bonjour,

                  Pas du tout ! Si dans le jeu de tables du site qui renvoyait l'erreur provoquant la page vierge il y a justement la tentative d'utilisation d'une extension ou incorrecte ou absente, un site vierge où tu utiliserais à la place de ses nouvelles tables les anciennes ne pourra réagir que comme le précédent.
                  Ta nouvelle installation n'a aucune raison de toucher aux anciennes tables, sauf si tu réutilises les mêmes préfixes, et dans ce cas, les anciennes tables sont sauvegardées ou supprimées (je ne me souviens pas s'il y a le choix au moment de l'installation), donc on repart systématiquement sur des tables neuves.

                  Autre point : si tu restaures une version 3 depuis une sauvegarde sans avoir supprimé toute trace des fichiers de version 4, tu as un mélange en principe détonnant !
                  "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


                  • #10
                    Hello
                    zamioculcas ... inbadreams
                    Tu es bien la même personne ???

                    Une install de Joomla ne touche pas aux tables sql ?
                    Et bien si car un CMS est TOUJOURS constitué de fichiers / dossiers ET des tables qui enregistrent toutes les données (pas seulement les articles d'ailleurs)

                    Si c'est le cas, c'est forcément un problème de déclaration quelconque du ovhconfig, htaccess ou du config.php non ?
                    Non !
                    ovhconfig et htaccess sont des fichiers qui communiquent avec le serveur
                    et pour le fichier de configuration de joomla c'est configuration.php

                    Comme te le signale Robert, le mélange de fichiers J3! et J4! c'est la catastrophe
                    Le mieux est de restaurer une sauvegarde COMPLETE ... ce qui veut dire tous les fichiers/dossiers ET aussi la base de donnée A LA MEME DATE
                    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


                    • #11
                      Bonjour Manu,
                      Oui, pardon, je suis bien zamioculcas ET inbadreams. Désolé pour la confusion.

                      J'allais répondre à Robert :


                      Merci Robert mais, le site fonctionnait très bien jusqu'à ce que je tente la MAJ vers J4. Je n'ai pas touché aux tables.
                      Si je te comprends bien, c'est lors de la MAJ que J4 a touché aux tables ? Or, lors de la MAJ en question, je n'ai pas dû spécifier quelles tables devaient être utilisées. Cela se fait seulement lors des install. C'est là où je me noie.

                      Chaque fois que j'ai réinstallé une version de Joomla, j'ai bien supprimé les fichiers existants (et j'ai fait une comparaison avec mon client FTP).

                      Du coup, je suis encore plus perdu.
                      Bien entendu, j'ai pensé à tout restaurer mais, ma dernière sauvegarde des tables date de... septembre 2020 et j'ai fait pas mal de MAJ depuis, profitant des confinements...

                      Commentaire


                      • #12
                        Lorsque tu fais une mise à jour ou migration, le site sait quelles tables modifier, celle du site en cours d'utilisation, il n'y a aucune raison qu'on crée des tables avec un autre préfixe que celui défini dans la configuration.

                        Si après plantage tu ne reviens pas à une version de la base d'avant l'échec, tu auras une structure qui ne correspond pas à la version de Joomla! utilisée et donc potentiellement des informations déjà modifiées par la mise à jour ou migration.

                        Donc comme le précise Manu, il te faut restaurer fichiers et base à une date antérieure à la tentative pour pouvoir repartir sur la version saine initiale.
                        D'ailleurs, compter sur les sauvegardes d'OVH ou d'autres hébergeurs n'est pour moi pas une bonne idée, sauf si elles concernent journellement, avec conservation pendant un certain temps, les fichiers et la base et permettent cette restauration du site à la même date.
                        Utiliser Akeeba backup est largement plus sûr, puisqu'on embarque par défaut l'ensemble des données et fichiers du site, et une doc on peut restaurer exactement ce qu'était le site lors de la sauvegarde.

                        Donc aujourd'hui, chez OVH, il te faudrait restaurer les fichiers ET la base d'avant l'incident du 3 octobre pour avoir une chance de retrouver un site fonctionnel en version 3.
                        "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


                        • #13
                          Or, lors de la MAJ en question, je n'ai pas dû spécifier quelles tables devaient être utilisées. Cela se fait seulement lors des install. C'est là où je me noie.
                          Pour que tu comprennes bien :
                          1. Lors d'une mise à jour ou d'une migration d'un site existant Joomla! est capable d'aller modifier les tables de la base de donnée car il a le profil complet de celle-ci enregistré dans sa configuration générale. Le préfixe ne sert qu'a différencier les tables au cas ou il y aurait plusieurs sites qui utiliseraient la même base de donnée (mas pas les mêmes tables bien évidemment)
                          2. Lors d'une installation toute neuve, Joomla ne peut pas savoir d'avance où et comment se connecter à une base de donnée car il n'a pas cette info. Il te demande donc de lui donner ces infos de connexion au moment de l'installation et un préfixe a utiliser (celui généré aléatoirement par Joomla ou celui que tu lui donneras) Joomla va donc s'y connecter, créer toutes les tables pour fonctionner et enregistrer ces infos dans la configuration générale de NOUVEAU site une fois pour toute
                          3. Une bonne sauvegarde d'un site Joomla, c'est obligatoirement les fichiers/dossiers du ftp ET la base de donnée complète qui contient TOUTES les tables A LA MEME DATE ... Et pour être sûr et certain que cette sauvegarde est saine, il faut la tester dans un environnement de test
                          https://kb.joomla.fr/procedures/sauvegarder-site-joomla
                          Dernière édition par manu93fr à 16/10/2021, 21h51
                          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


                          • #14
                            Bonjour messieurs,
                            Encore merci pour vos retours.
                            J'ai bien compris que j'ai fait une monumentale erreur en pensant que la migration se ferait sans prendre les précautions nécessaires que vous et tout le monde recommandez.
                            Mon problème, à présent que les constatations sont faites, c'est qu'il me reste à revenir à la dernière sauvegarde des tables, c'est-à-dire septembre 2020. C'est-à-dire un site à qui il va manquer beaucoup d'articles.
                            Ce n'est qu'une sorte de blog et je ne fais qu'y soliloquer, il n'a donc aucune espèce d'importance... sauf pour moi :-)
                            En l'occurrence, j'ai perdu toutes les élucubrations de ces douze derniers mois. En théorie.
                            Je me pose une question : mes erreurs ont modifié l'accès de Joomla à mes tables, c'est ce que je comprends de vos messages mais, qu'en est-il du texte des articles eux-mêmes ? Il n'a pas disparu, je suppose ? En l'état, ces textes sont inexploitables par une install Joomla mais n'existe-t-il pas un moyen de récupérer le texte brut des articles les plus récents (sept2020-oct2021) ? Si je peux faire ça, moyennant un passage sur traitement de texte et des coper/coller, je pourrais refaire tous mes articles. Évidemment, ça fait du boulot mais j'ai du temps entre les mains. C'est toujours mieux que tirer un trait sur douze mois d'articles.
                            J'ai retrouvé la trace d'articles récents grâce à des mots-clefs sur la base quelques jours seulement après mes bêtises, c'est donc bien que la substance des articles est présente. Donc extractible ?
                            NB : en tout cas, finies les mises à jour sans précaution. Mais, c'est bien que ça me serve de leçon puisque je maintiens le site d'un auteur de SF et je serais bien ennuyé si j'avais fait ces mêmes bêtises avec son site...

                            Commentaire


                            • #15
                              Si tu es chez OVH, tu as à disposition dans ton Manager les 30 dernières sauvegardes de la base, pourquoi restaurerais-tu une base de septembre 2020 ?
                              "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

                              Annonce

                              Réduire
                              Aucune annonce pour le moment.

                              Partenaire de l'association

                              Réduire

                              Hébergeur Web PlanetHoster
                              Travaille ...
                              X