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 chez PHPNET, sites perso chez PlanetHoster + sites gérés chez PHPNET, PlanetHoster, Ionos 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 chez PHPNET, sites perso chez PlanetHoster + sites gérés chez PHPNET, PlanetHoster, Ionos 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 chez PHPNET, sites perso chez PlanetHoster + sites gérés chez PHPNET, PlanetHoster, Ionos 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 chez PHPNET, sites perso chez PlanetHoster + sites gérés chez PHPNET, PlanetHoster, Ionos 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 chez PHPNET, sites perso chez PlanetHoster + sites gérés chez PHPNET, PlanetHoster, Ionos 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 chez PHPNET, sites perso chez PlanetHoster + sites gérés chez PHPNET, PlanetHoster, Ionos et OVH

            Commentaire


            • #7
              Salut
              Merci d'avoir évoqué la piste du htaccess
              J'avai le même problème d'affichage et de gestion du backoffice seulement !
              j'ai enlevé
              Code:
              ## These directives are only enabled if the Apache mod_headers module is enabled.
              ## This section will check if a .gz file exists and if so will stream it
              ## directly or fallback to gzip any asset on the fly
              ## If your site starts to look strange after enabling this, and you see
              ## ERR_CONTENT_DECODING_FAILED in your browser console network tab,
              ## then your server is already gzipping css and js files and you don't need this
              ## block enabled in your .htaccess
              <IfModule mod_headers.c>
              # Serve gzip compressed CSS files if they exist
              # and the client accepts gzip.
              RewriteCond "%{HTTP:Accept-encoding}" "gzip"
              RewriteCond "%{REQUEST_FILENAME}\.gz" -s
              RewriteRule "^(.*)\.css" "$1\.css\.gz" [QSA]
              
              # Serve gzip compressed JS files if they exist
              # and the client accepts gzip.
              RewriteCond "%{HTTP:Accept-encoding}" "gzip"
              RewriteCond "%{REQUEST_FILENAME}\.gz" -s
              RewriteRule "^(.*)\.js" "$1\.js\.gz" [QSA]
              
              # Serve correct content types, and prevent mod_deflate double gzip.
              RewriteRule "\.css\.gz$" "-" [T=text/css,E=no-gzip:1]
              RewriteRule "\.js\.gz$" "-" [T=text/javascript,E=no-gzip:1]
              
              <FilesMatch "(\.js\.gz|\.css\.gz)$">
              # Serve correct encoding type.
              Header append Content-Encoding gzip
              
              # Force proxies to cache gzipped &
              # non-gzipped css/js files separately.
              Header append Vary Accept-Encoding
              </FilesMatch>
              </IfModule>
              et tout fonctionne bien
              Seul truc contrariant, je n'ai pas compris purquoi, j'ai plusieurs sites qui ont à priori la même configuration (et je n'ai pas modifié qq chose chez l'hébergeur) et pourquoi celui là?
              Faciliter l'adoption du meilleur du Libre auprès du grand public https://clibre.eu/ - Connaissez-vous des communicants ... pour promouvoir joomla ? https://forum.joomla.fr/forum/th%C3%A8mes-communautaires/tout-et-rien/2027647-connaissez-vous-des-graphistes-communicants-pour-promouvoir-joomla

              Commentaire

              Annonce

              Réduire
              Aucune annonce pour le moment.

              Partenaire de l'association

              Réduire

              Hébergeur Web PlanetHoster
              Travaille ...
              X