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.
bug du template d’administration
Réduire
X
-
-
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:
-
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:
-
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:
-
-
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:
-
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:
-
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:
-
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:
-
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:
-
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:
-
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:
-
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:
-
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.
Laisser un commentaire: