Blocage en Back End pour une restauration avec Akeeba kickstart 7.1.0

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

  • [RÉGLÉ] Blocage en Back End pour une restauration avec Akeeba kickstart 7.1.0

    Bonjour à tous, toutes,

    J'ai une archive de 2018 d'un site www.xxx-xxx.com que j'ai sauvegardé à l'époque en .zip grâce à Akeeba Backup.
    Je veux le placer sur un nouvel hébergement pour un autre nom de domaine www.yyy-yyy.com
    J'ai donc placé sur le serveur avec FTP FileZilla : le fichier.zip puis le fichier kickstart.php et son fichier en-GB.kickstart.ini
    J'ai lancé kickstart.php et suivi les procédures et paramétrages.
    L’installation s'effectue correctement.

    Le site fonctionne parfaitement en Front Office !

    Mais dès que je passe en /administror/index.php (BackEnd), malgré le fait que je mette mon identifiant et mot de passe ; quand je valide je tombe sur une page blanche.

    Avec comme code source :

    Code HTML:
    <div class="row-fluid"> <div class="span3">  <div class="cpanel-links">
    Et pas plus !
    J'ai tourné un moment mais là je ne voit pas et je vous demande votre expertise...

    J'ai lancé la procédure de restauration pour le redémarrer et faire les mises à jour sur la version PHP 5.6.40 (exécution legacy et moteur php).
    La base de donnée est MySQL 5.6
    Joomla est en version 3.8.11
    Sur le site je ne trouve pas le fichier web.config, php.ini et .user.ini : est-ce important ?

    Je ne comprends pas pourquoi il marche en Front Office sans problème et se bloque en Back Office dès la validation du mot de passe.

    P.S. : J'ai changé avec phpMyAdmin mon mot de passe sur la table zzz_users, le champ password puis mis md5 avant d'éxécuter.
    J'ai regardé de nouveau ce champ et il est correctement codé.
    Le champ lastvisitDate de cette table à été mis à jour, donc on peut dire qu'il écrit bien dans la base de données.

    Merci de m'avoir lu !

    J'espère avoir des suggestions ou des réponses
    En attendant je vous souhaite le meilleur !

    Andéa
    Dernière édition par Andéa à 19/10/2021, 16h39

  • #2
    Bonjour,

    Commence par modifier ton fichier configuration.php en passant les variables debug à "1" et error_reporting à "development" pour essayer de faire apparaître l'extension en cause.
    "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 et sites perso chez PlanetHoster + sites gérés chez PHPNET, 1and1 et OVH

    Commentaire


    • #3
      Bonjour,

      J'ai déjà eu ce type de problème à cause des lignes cookie_path, cookie_domain, live_site qui n'étaient pas vides dans le fichier configuration.php.

      Peut-être une piste ?

      Autre piste, utilisez-vous des extensions de sécurité complémentaire style akeeba admintools ?

      Pascal
      If anything can go wrong, it will...
      If I can help, I will ..https://conseilgouz.com

      Commentaire


      • #4
        Bonjour,

        D'abord, merci pour vos retours !

        live_site lui n'était pas vide et comporté l'URL du nouveau site. J'ai donc vider.
        cookie_path et cookie_domain sont bien vides.
        .
        Ensuite j'ai passé debug à 1 et error_reporting à "development"
        J'ai bien la console de débogage Joomla enbas de la page d'accueil du Back Office.

        Je ne sait pas trop où regarder.
        Sur le slide Session je ne vois rien de spécial.
        Donc je vais sur la partie : Requête de base de données et ouvre le slide.

        J'ai :
        4 doubles découverts!
        2 requêtes dupliquées: #8 #9
        2 requêtes dupliquées: #15 #17

        Puis je descends :
        • sur la table xxx_viewlevels key INDEX N'A PU ÊTRE UTILISÉ
        • sur la table xxx_extension Extra m'indique :Using index condition; Using where; Utilisation du tri complet de type filesort
        • sur #8 et #9 j"ai bien cette notion de requêtes dupliquées
          • #8 la table xxx_templates_styles donne sur key INDEX N'A PU ÊTRE UTILISÉ
          • #9 pareil
        • sur la table xxx_rokcommon_configs, key INDEX N'A PU ÊTRE UTILISÉ extra Utilisation du tri complet de type filesort
        • sur la table xxx_assets key INDEX N'A PU ÊTRE UTILISÉ
        • #15 :Requêtes dupliquées: #17 (table xxx_extensions)
        • #17 Requêtes dupliquées: #15 (table xxx_extensions)
        • sur la table xxx_rokcandy key INDEX N'A PU ÊTRE UTILISÉ
        • sur la table xxx_template_style INDEX N'A PU ÊTRE UTILISÉ
        • #23 sur une requête SELECT ... FROM xxx_modules ... LEFT JOIN xxx_extensions AS... j'aisur Extra : Using index condition; Using where; Utilisation du tri complet de type filesort
        • #25 sur une requête SELECT ... FROM xxx_modules ... LEFT JOIN xxx_modules_menu AS...LEFT JOIN xxx_extensions... j'ai sur Extra : Using index condition; Using where; Utilisation du tri complet de type filesort
        Vous l'avez compris j'utilise un template et extensions de la société rockettheme.

        Mais là je ne sait pas quoi faire, vos expertises me sont nécessaire.

        De vous lire, pour avancer, je vous salut bien bas.

        Andéa.

        Commentaire


        • #5
          Ce n'est pas ça qui est intéressant, mais ce qui pourrait s'afficher sur la page qui est vierge après identification.
          "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 et sites perso chez PlanetHoster + sites gérés chez PHPNET, 1and1 et OVH

          Commentaire


          • #6
            Re,

            C'est toujours pareil.
            La page est vide, vierge.
            Le code source et le même :


            Code HTML:
            <div class="row-fluid"> <div class="span3"> <div class="cpanel-links">
            Merci de votre aide.

            Commentaire


            • #7
              Il est étonnant qu'après identification à l'administration le débogage n'affiche rien d'autre que la page blanche, ce qui voudrait dire qu'il n'est pas utilisé.
              "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 et sites perso chez PlanetHoster + sites gérés chez PHPNET, 1and1 et OVH

              Commentaire


              • #8
                Re,
                n’aurait t'on pas oublié un truc dans la configuration d'un fichier. config.php, php.ini .user.ini ... ?
                Vu que la base de données n'est pas la même (pas le même nom),
                Le Front End ne marcherait pas si la base est mal configurée.
                Or le Front End fonctionne correctement avec le template et les extensions de RocketTheme.
                Est-ce un problème sur JCE ?

                Dans le fichier configuration.php je ne comprends pas la valeur de la variable $secret
                Il y a aussi des variables à localhost

                Peut-on désactivé à la main JCE ou un template d'un ficher.php et Notepad++ et FilleZilla

                Merci à vous tous de me suivre sur ce fil.

                Andéa

                Commentaire


                • #9
                  Bonjour,

                  Puisque tu as restauré une sauvegarde Akeeba, tu as dû lui donner les informations concernant la nouvelle base de données, et par défaut les valeurs des chemins vers les dossiers logs et tmp sont adaptées au changement de serveur.

                  Il n'y a pas de "user.ini" dans Joomla!, si tu en vois un, il vient d'une source externe, extension par exemple. Un php.ini c'est a priori pareil. Et ils n'ont pas d'impact à mon sens, ici.

                  La variable "secret" est à usage interne, je ne m'en suis jamais préoccupé. La modifier n'a à mon sens d'intérêt, que lorsqu'on clone un site peut-être, mais même là, je n'y pense pas...

                  La seule chose importante est ce qui définit la base de données et son mot de passe.

                  Au besoin, contacte-moi par MP
                  "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 et sites perso chez PlanetHoster + sites gérés chez PHPNET, 1and1 et OVH

                  Commentaire


                  • #10
                    Bonjour et merci !

                    Oui, ok.
                    J'ai restauré encore une fois mon fichier site-anciennomdedomaine-2018xxxx-xxx.zip avec kickstart.php
                    Et là ce suis allé plus loin dans les réglages.
                    Oui Angie d'akeeba le dit et ne détecte pas de .user.ini ni de php.ini donc propose de ne pas cocher l'option.
                    Le Front End répond bien présent partout..
                    L'accès au Back Office à bien lieu et le champ (de la base de donnée) lastvisiteDate de la table xxx_users confirme un changement et une bonne date (2021-10-11 22:01).

                    On peut donc en déduire que la base de données et bien sollicitée autant en FO qu'en BO.
                    Les dossiers log et temp ont été bien réglé.
                    configuration.php semble comporter les bon réglage, le nouveau nom de domaine, les chemins et les variables MySQL semble correct aussi ( et le FO fonctionne)..
                    Après l'identification en BO, la table xxx_users sur le champ lastvisitDate est mise à jour avec la bonne date-heure en UTC.
                    J'ai modifié dans cette table le mot de passe pour un nouveau avec demande MD5 sur le champ password. Le champ password à l'air de s'être bien crypté.

                    La seule chose importante est ce qui définit la base de données et son mot de passe.
                    Je pense que c'est bon puisque le site en FO fonction avec ses données (articles, menu...etc)
                    En BO on a bien un changement de date sur lastvisiteDate de la table xxx_users

                    La variable $secret à changée dans configuration.php.
                    Pour un info, j'ai lu sur un forum, elle serait un "jeton" du site pour donner certains paramètres sur les extensions ou autres...

                    Pour logs et tmp le chemin semble correct (le fichier logs contient un error.php qui indique un message : Le mot de passe ne correspond pas au nom d'utilisateur, ou vous n'avez pas encore de compte. Mais ça c'était pour une ancienne date de connexion.

                    Il n' a rien dans le dossier tmp et cela n'étonne.
                    J'ai aussi pas mal de variable dans configuration.php égale à localhost, et là cela m'interroge.
                    exemple :

                    $memcache_server_host = 'localhost'
                    J'y bosse mais je ne trouve rien depuis des heures.

                    Merci de votre contribution !

                    Andéa

                    Commentaire


                    • #11
                      Arrête-toi là !
                      Va dans la configuration depuis l'administration, et contente-toi d'enregistrer et quitter. Ces localhost ne pouvant pas se définir dans la gestion de la configuration, il n'y a pas lieu de toucher au fichier lui-même.
                      Cependant, pour moi, la variable "live_site" doit toujours être vide, sauf très rares exceptions.
                      "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 et sites perso chez PlanetHoster + sites gérés chez PHPNET, 1and1 et OVH

                      Commentaire


                      • #12
                        Je viens de trouver un truc louche :
                        Il existe un fichier install.script.php à la racine (root) provenant de chez RocketTheme

                        Si on l'ouvre il indique :
                        • The RocketLauncher package should not be installed into an existing Joomla instance. It is a stand-alone Joomla installation.
                        soit en Fr :
                        • Le package RocketLauncher ne doit pas être installé dans une instance Joomla existante. Il s'agit d'une installation Joomla autonome.
                        Est ce la clé du problème ?
                        Et comment faire ?
                        Ce n'est pas mon cas puisque je ne fais que de la restauration.

                        Pour avoir le cœur net, je suis allé décompresser l'archive site-anciennomdedomaine-2018xxxx-xxx.zip
                        Ce fichier existe bien depuis 2015.
                        Donc cela n'a pas l'air de venir de là .

                        Rien à faire encore.
                        Je me demande, à ce stade, si je ne devrais pas réinstaller Joomla avec le template de RocketTheme et ses extensions........
                        Repartir de zéro quoi.

                        Quand pensez-vous ?

                        Commentaire


                        • #13
                          Arrête-toi là !
                          Va dans la configuration depuis l'administration, et contente-toi d'enregistrer et quitter. Ces localhost ne pouvant pas se définir dans la gestion de la configuration, il n'y a pas lieu de toucher au fichier lui-même.
                          Ok, mais je comprend pas... dans la pratique.
                          Je passe par FilleZilla sur configuration.php sur le serveur ?

                          Va dans la configuration depuis l'administration,
                          Je n'ai pas accès à l'adminsitration puisque ça bloque après l’identification dans le BO pour me donner que :
                          Code HTML:
                          <div class="row-fluid"> <div class="span3"> <div class="cpanel-links">
                          Code de la fameuse page vierge...

                          Commentaire


                          • #14
                            Il est probable que ce site a été initialement créé à partir d'un quickstart. A mon avis, tu peux le supprimer.

                            Mais tu ne viens pas de dire (message #10) que tout fonctionnait après cette nouvelle restauration ? Pourquoi voudrais-tu repartir de zéro ? Je ne te suis vraiment plus.
                            "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 et sites perso chez PlanetHoster + sites gérés chez PHPNET, 1and1 et OVH

                            Commentaire


                            • #15
                              Merci,

                              Tout fonctionne en FO n'est pas en BO.
                              J'ai dit en #10 que :

                              Le Front End répond bien présent partout..
                              L'accès au Back Office à bien lieu et le champ (de la base de donnée) lastvisiteDate de la table xxx_users confirme un changement et une bonne date (2021-10-11 22:01).

                              On peut donc en déduire que la base de données et bien sollicitée autant en FO qu'en BO.
                              J'ai oublié de préciser que le BO ne fonctionne toujours pas, malgré une page d'accueil invitant à s'identifier, puis passage à une page blanche avec comme code source :

                              Code HTML:
                              <div class="row-fluid"> <div class="span3"> <div class="cpanel-links">
                              et rien de plus

                              Le site à été installé par un fichier de RocketTheme de mémoire.
                              Je ne sais plus mais peut être que Rockettheme proposé un package Joomla + template et extension.
                              J'ai peut être du l'installer par ce qu'ils disent : Joomle 3.x RocketLancher

                              Si c'est cela c'est "cuit" ?
                              Pourtant le Front Office fonctionne

                              Merci

                              Andéa

                              Commentaire

                              Annonce

                              Réduire
                              1 sur 2 < >

                              C'est [Réglé] et on n'en parle plus ?

                              A quoi ça sert ?
                              La mention [Réglé] permet aux visiteurs d'identifier rapidement les messages qui ont trouvé une solution.

                              Merci donc d'utiliser cette fonctionnalité afin de faciliter la navigation et la recherche d'informations de tous sur le forum.

                              Si vous deviez oublier de porter cette mention, nous nous permettrons de le faire à votre place... mais seulement une fois
                              Comment ajouter la mention [Réglé] à votre discussion ?
                              1 - Aller sur votre discussion et éditer votre premier message :


                              2 - Cliquer sur la liste déroulante Préfixe.

                              3 - Choisir le préfixe [Réglé].


                              4 - Et voilà… votre discussion est désormais identifiée comme réglée.

                              2 sur 2 < >

                              Assistance au forum - Outil de publication d'infos de votre site

                              Compatibilité: PHP 4.1,PHP4, 5, 6DEV MySQL 3.2 - 5.5 MySQLi from 4.1 ( @ >=PHP 4.4.9)

                              Support Version de Joomla! : | J!3.0 | J!2.5.xx | J!1.7.xx | J!1.6.xx | J1.5.xx | J!1.0.xx |

                              Version française (FR) D'autres versions sont disponibles depuis la version originale de FPA

                              UTILISER À VOS PROPRES RISQUES :
                              L'exactitude et l'exhaustivité de ce script ainsi que la documentation ne sont pas garanties et aucune responsabilité ne sera acceptée pour tout dommage, questions ou confusion provoquée par l'utilisation de ce script.

                              Problèmes connus :
                              FPA n'est actuellement pas compatible avec des sites Joomla qui ont eu leur fichier configuration.php déplacé en dehors du répertoire public_html.

                              Installation :

                              1. Téléchargez l'archive souhaitée : http://afuj.github.io/FPA/

                              Archive zip : https://github.com/AFUJ/FPA/zipball/master

                              2. Décompressez le fichier de package téléchargé sur votre propre ordinateur (à l'aide de WinZip ou d'un outil de décompression natif).

                              3. Lisez le fichier LISEZMOI inclus pour toutes les notes de versions spécifiques.

                              4. LIRE le fichier de documentation inclus pour obtenir des instructions d'utilisation détaillées.

                              5. Téléchargez le script fpa-fr.php à la racine de votre site Joomla!. C'est l'endroit que vous avez installé Joomla et ce n'est pas la racine principale de votre serveur. Voir les exemples ci-dessous.

                              6. Exécutez le script via votre navigateur en tapant: http:// www. votresite .com/ fpa-fr.php
                              et remplacer www. votresite .com par votre nom de domaine


                              Exemples:
                              Joomla! est installé dans votre répertoire web et vous avez installé la version française du fichier FPA:
                              Télécharger le script fpa-fr.php dans: /public_html/
                              Pour executer le script: http://www..com/fpa-fr.php

                              Joomla! est installé dans un sous-répertoire nommé "cms" et vous avez installé la version française du fichier FPA:
                              Télécharger le script fpa-fr.php dans: /public_html/cms/
                              Pour executer le script: http://www..com/cms/fpa-fr.php

                              En raison de la nature très sensible de l'information affichée par le script FPA, il doit être retiré immédiatement du serveur après son utilisation.

                              Pour supprimer le script de votre site, utilisez le lien de script de suppression fourni en haut de la page du script. Si le lien de suppression échoue pour supprimer le script, utilisez votre programme FTP pour le supprimer manuellement ou changer le nom une fois que le script a généré les données du site et le message publié sur le forum. Si le script est toujours présent sur le site, il peut être utilisé pour recueillir suffisamment d'informations pour pirater votre site. Le retrait du script empêche des étrangers de l'utiliser pour jeter un oeil à la façon dont votre site est structuré et de détecter les défauts qui peuvent être utilisé à vos dépends.
                              Voir plus
                              Voir moins

                              Partenaire de l'association

                              Réduire

                              Hébergeur Web PlanetHoster
                              Travaille ...
                              X