Plantage de l'administration ?

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

  • [RÉGLÉ] Plantage de l'administration ?

    Bonjour,

    Alors que je travaillais sur un site en 4.0.3 et que j'ai fait autre chose, lorsque je suis revenu sur l'administration quelques minutes plus tard, l'interface a planté, plus d'utilisation du template Atum.
    Il me semble que j'étais sur la page de paramétrage du style du template. Le site utilise un template Joomlaplates basé sur Astroid et des modules UIkit. Le frontal ne pose pas de problème.

    En tête de page, alors que j'utilise Firefox, mais même problème avec Chrome, le message "Attention, le navigateur Internet Explorer ne doit pas être utilisé pour un bon fonctionnement de l'interface d'administration." s'affiche, puis les liens empilés et le formulaire ressemble à ça :
    Cliquez sur l'image pour l'afficher en taille normale  Nom : formulaire_erreur.jpg  Affichages : 19  Taille : 20,8 Ko  ID : 2031945
    Impossible de faire quoi que ce soit.
    Avant de restaurer une sauvegarde datant d'avant-hier, je préfèrerais essayer de comprendre la cause de ce bug ! J'ai quand même une sauvegarde de la base datant de ce matin.

    Merci de vos conseils !
    Robert
    Dernière édition par RobertG à 05/10/2021, 10h33
    "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

  • #2
    Bonjour,

    La restauration de la base, sauvegarde d'hier matin, n'a eu aucun effet. Le site étant chez OVH, j'ai demandé une restauration du serveur à J-1, mais ça traîne.
    Alors j'ai voulu savoir si l'activation du débogage et le rapport d'erreurs au maximum m'apporteraient des informations. Miracle, ça a remis l'administration en route !
    Après nouvel essai, il est indispensable que le débogage soit activé pour que l'administration fonctionne !

    Tant que la restauration du serveur par OVH ne sera pas terminée, je suis bloqué dans mes recherches. Depuis un peu plus d'une heure, la tâche de restauration de snapshot est "planifiée"...

    Si quelqu'un a une idée de la raison d'une telle anomalie au niveau du débogage, je suis preneur !
    "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
      En complément : le débogage n'affiche strictement rien, mais côté site, la console affiche
      Uncaught TypeError: PhpDebugBar.Widgets.InfoWidget is not a constructor
      Et côté administration, en plus de ce message :
      La ressource à l’adresse « https://w ww.*************.com/.../css/uikit.css » a été bloquée en raison d’un type MIME (« text/html ») incorrect (X-Content-Type-Options: nosniff).
      index.php
      La ressource à l’adresse « https://w ww.*************.com/...t3/js/uikit.js » a été bloquée en raison d’un type MIME (« text/html ») incorrect (X-Content-Type-Options: nosniff).
      index.php
      La ressource à l’adresse « https://w ww.*************.com/...uikit-icons.js » a été bloquée en raison d’un type MIME (« text/html ») incorrect (X-Content-Type-Options: nosniff)
      Je m'aperçois que le plus important peut-être dans ces erreurs UIkit, c'est la recherche des fichiers dans "nom_de_domaine/administrator/plugins"
      Reste à trouver la cause de cette erreur de chemin...
      Dernière édition par RobertG à 05/10/2021, 08h54
      "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


      • #4
        Bien, en remplaçant JURI::base() dans le plugin UIkit par JURI::root(), les fichiers sont bien cherchés où il faut et l'erreur a disparu de la console.

        Il teste celle de debugbar !

        Curieusement, sur une copie locale du site, cette erreur debugbar n'apparaît pas !
        "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


        • #5
          Pour résumer :
          - en ligne, le site fonctionne ; l'administration ne fonctionne que si le débogage est activé, mais lorsqu'il est activé, il y a cette erreur de widget debugbar ;
          - en local, le site fonctionne, l'administration fonctionne que le débogage soit activé ou désactivé

          La seule différence étant le fichier .htaccess (aeSecure en ligne, standard en local), j'ai désactivé puis fait quelques tests en supprimant tous les backups de ce fichier en ligne. Il n'y a que la désactivation d'aeSecure qui règle le problème. Je ne comprends vraiment pas ce qui peut s'être si brutalement passé pour que cela survienne.
          "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
            Bonjour,

            Suite et colère !
            Alors que le site fonctionnait, il n'était plus nécessaire de restaurer le serveur OVH, d'autant qu'après plus de 4 heures, ça n'avait toujours pas démarré. L'assistance interrogée m'a répondu qu'une restauration prenait entre 12 et 72 heures : ne comptez donc pas sur cette fonctionnalité si vous devez rapidement remettre en route un site chez OVH !
            A ma demande, puisqu'on ne peut pas le faire depuis le Manager, le technicien a bien voulu annuler cette restauration.
            Quelques heures plus tard, le site renvoyait une erreur 500 alors que personne n'y avait touché depuis la fin de matinée... Première chose : je supprime le fichier .htaccess, bien qu'il n'ait pas généré d'erreur quelques heures plus tôt. Je mets un fichier pour seulement tester la version de PHP : erreur 500.
            Je crée un nouveau dossier, j'y transfère ce fichier et le favicon, et je modifie le pointage du nom de domaine : toujours une erreur 500 !
            J'ouvre un ticket en expliquant ce qui se passe et qu'il n'y a que ces deux fichiers dans le dossier, et je reçois une réponse issue d'une base de connaissance à propos des erreurs 500, sans aucun rapport avec la situation !
            Qu'ont-ils fait malgré cette réponse ? Je l'ignore, mais vers 23 heures, l'erreur 500 avait disparu et j'ai pu restaurer le site ce matin.
            Encore un mystère OVH !
            "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

            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