bug du template d’administration

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

  • RobertG
    a répondu
    C'est sur une page où tu as l'erreur ou une autre qui fonctionne ?
    La consommation de mémoire est à 12 Mo si j'ai bien lu; donc bien loin de ce que dit le message d'erreur.
    Les requêtes en double, c'est habituel, mais je ne saurais dire pour quelle raison ça se produit, faute d'avoir vraiment pris le temps un jour de vérifier.

    Laisser un commentaire:


  • Peggy
    a répondu
    oui j'utilise le template d'administration ISIS.
    Voici ce que dit la console de debug en back office. voir fichiers joints.
    Fichiers joints

    Laisser un commentaire:


  • RobertG
    a répondu
    Celles à supprimer ? Comment pourrait-on te le dire puisque tu s flouté tous les titres ?
    Tu as donc encore la même erreur aux mêmes trois niveaux, et toujours pas d'info supplémentaire en activant le débogage et en mettant le rapport d'erreur à "développement" (à écrire "development" si tu dois le faire directement dans le fichier de configuration) ?

    Au fait, tu utilises bien le template d'administration "Isis" ?

    Laisser un commentaire:


  • Peggy
    a répondu
    La question n'était pas celle des lignes à conserver mais de celle à supprimer. Tans pis, j'ai supprimé les lignes qui me paraissait les plus récentes, c'est à dire celles portant l'ID le plus grand.
    Le back office reste inchangé.

    Laisser un commentaire:


  • RobertG
    a répondu
    Par défaut, on a les accès "public", "enregistré", "spécial", "invité" et "super utilisateur". Il ne faut donc surtout pas supprimer ce dernier pour pouvoir accéder à l'administration pour tes tests.
    Au pire, il te faudrait remettre ta sauvegarde de la table et recommencer.

    Laisser un commentaire:


  • Peggy
    a répondu
    Quand tu dis "supprimer une à une les lignes les plus récentes des niveaux d'accès". Est-ce qu'il s'agit des lignes dont l'ID est le plus gros/grand ? (30, 31, 32 par exemple. Voir copie d’écran)
    Fichiers joints

    Laisser un commentaire:


  • RobertG
    a répondu
    Ce que tu peux faire en local, c'est de d'abord faire une sauvegarde de la table "#__viewlevels" puis de supprimer une à une les lignes les plus récentes des niveaux d'accès pour voir si à un moment, ce dépassement de mémoire disparaît. Il faut que tu conserves les lignes dont l'ID va de 1 à 8
    La première étape est de comprendre. Ensuite on essaiera de trouver une parade.

    Laisser un commentaire:


  • Peggy
    a répondu
    Bonjour RobertG,
    ça y est j'ai une sauvegarde jpa qui tourne en local.
    En local, le back office présente les mêmes bugs. Et le front office est opérationnel.

    Laisser un commentaire:


  • RobertG
    a répondu
    memory_limit à -1, c'est aucune limite, ce qui ne va pas du tout avec l'erreur qui concerne un dépassement de mémoire !
    Pour ce qui est de la sauvegarde, tu peux en tenter une sans les dossiers lourds (soit tout "images", soit seulement les plus gros qu'il contient).
    Pourquoi une sauvegarde en zip et pas en jpa ?

    Laisser un commentaire:


  • Peggy
    a répondu
    Dans l'onglet "informations PHP" des "informations système" : memory_limit local value : -1 master value : -1


    Je n'arrive pas à décompresser le dossier de sauvegarde zip. Il pèse 1.3Go (il y a beaucoup d'images sur ce site web).

    une erreur inattendue vous empêche de copier le fichier... erreur non spécifiée sur :
    - readme.html
    - extrainfo
    - defines.php
    - version.php
    - etc...

    si je clic sur "ignorer" il me dit que le même volume ne peut pas être utilisé à la fois comme source et comme destination.
    J'ai tenté de le décompresser sur un autre volume mais le message est le même.

    Laisser un commentaire:


  • RobertG
    a répondu
    OK, mais ce que je n'arrive pas à comprendre c'est ce qui peut déclencher un dépassement de mémoire, dont la limite est par défaut à 512 Mo dans la configuration OVH (cherche memory_limit dans l'onglet PHP des infos système).
    Il faudrait tester une copie sur un serveur (local ?) où la quantité de mémoire peut être modifiée de manière simple (ce qui ne résoudra pas pour autant le problème chez OVH, sauf à pouvoir agir sur la cause de cette quantité de mémoire demandée).

    Laisser un commentaire:


  • Peggy
    a répondu
    Non, sur les pages du back office qui sont bugguées, il n'y a pas de tableau, pas de console de débogage.
    Les copies d'écrans envoyées précédemment sont toujours d'actualité et le même message revient :

    Fatal error: Out of memory (allocated 616562688) (tried to allocate 262144 bytes) in /homepages/0/d575407934/htdocs/joomla/libraries/src/Helper/UserGroupsHelper.php on line 295

    Fatal error: Out of memory (allocated 616562688) (tried to allocate 262144 bytes) in Unknown on line 0

    Fatal error: Out of memory (allocated 616562688) (tried to allocate 262144 bytes) in Unknown on line 0

    Laisser un commentaire:


  • RobertG
    a répondu
    Sur les pages incorrectes, tu n'as pas une série de lignes dans un tableau avec les fichiers par lesquels on est passé et la ligne concernée ? C'est ça qui pourrait nous en apprendre plus.

    Laisser un commentaire:


  • Peggy
    a répondu
    Bonjour,
    Je vois maintenant la console de débogage joomla.
    Par exemple en back office, sur la console de requêtes de base de données : 8 doubles découverts.
    Parmi ces requêtes dupliquées il y a :
    la table users, la table user_usergroup_map,
    la table viewlevels avec "index n'a pu être utilisé",
    la table template_styles avec "Utilisation du tri complet de type filesort"


    sur mes pages du back office qui sont bugguée, la console n'apparaît pas.

    Laisser un commentaire:


  • RobertG
    a répondu
    Il faut en effet d'abord que tu modifies les droits en 644 pour pouvoir enregistrer ton fichier de configuration.

    Laisser un commentaire:

Annonce

Réduire
Aucune annonce pour le moment.

Partenaire de l'association

Réduire

Hébergeur Web PlanetHoster
Travaille ...
X