Erreur fatale dans les pages d'administration

15

J'ai installé magento 1.7 et cela a bien fonctionné jusqu'à présent.

J'importe des produits quotidiennement. S'il y a un nouveau fabricant, je l'ajoute dans l'attribut Fabricant basé sur la liste déroulante.

Aujourd'hui, j'ai ajouté une nouvelle option Fabricant dans le back-end d'attribut et je suis allé importer des produits avec succès.

Mais après cela, j'essaie d'ouvrir n'importe quelle page du site d'administration de Magento, cela se termine par un message d'erreur ci-dessous

Erreur fatale: impossible de remplacer la méthode finale Mage_Core_Model_Abstract :: clearInstance () dans /var/www/html/app/code/core/Mage/Catalog/Model/Category.php sur la ligne 36

La ligne 36vient de commencer bouclée {pour cette classe

class Mage_Catalog_Model_Category extends Mage_Catalog_Model_Abstract
{ <-- this is line 36

Et j'ai vérifié Mage_Catalog_Model_Categorymais il n'y a pas de méthode définie avec le nomclearInstance . C'est vraiment ennuyeux.

FYI: Je n'ai pas touché un seul caractère de code J'utilise simplement le site ADMIN pour importer des produits et ajouter certains attributs requis

lumière du soleil
la source
Pourquoi -1? Je suis ici pour aider les gens. N'est-ce pas un endroit pour poser des questions sur Magento.
soleil
Environ -1, parfois les gens réagissent bizarrement ... A propos de votre problème, il est écrit dans votre message d'erreur, lisez-le. "NE PEUT PAS REMPLACER LA MÉTHODE FINALE ...". Vous essayez de passer outre quelque chose qui ne peut pas (vous ou quelqu'un qui le code mal)
Sylvain Rayé
@ SylvainRayé: Je n'avais même pas touché un seul caractère de code, avez-vous lu la question?, J'utilise simplement le site ADMIN pour importer des produits. C'est Magento qui lance une erreur et encore une fois c'est Magento qui le code mal
lumière du soleil
@ SylvainRayé: L'erreur n'est pas aussi légère que vous le pensez, surtout quand elle provient du code principal et même sans toucher au code.
soleil
Les fées downvote sont assez agressives dans cette communauté, ignorez-les. Il peut s'agir d'un problème lorsqu'une extension tierce cause le problème en étendant ou en remplaçant la classe. Essayez de désactiver toutes les extensions tierces pour voir si cela vous aide
Sander Mangel

Réponses:

5

Ce comportement ne se produirait normalement que si vous avez modifié le code de Magento d'une manière ou d'une autre - que ce soit via des extensions tierces, des modifications de code de base ou des personnalisations générales.

Le fait que cela se produise dans l'administrateur, avant que les modèles de données ne soient réellement chargés (grille de produits, etc.) impliquerait qu'il soit causé par une extension - et non par des données importées.

Si cela se produisait sur la grille de produits - il pourrait s'agir du modèle de produit en cause en raison d'un échec de l'importation.

Mais après une recherche rapide, il y a beaucoup de résultats de recherche google indexés des magasins Magento avec la même erreur. Donc ça pourrait être au cœur (bien que nous ne l'ayons jamais rencontré) - mais je suis douteux.

Regarder le noyau en 1.7

+34 abstract class Mage_Catalog_Model_Abstract extends Mage_Core_Model_Abstract
+35 {
+36     /**
+37      * Identifuer of default store

Vous ne devriez pas avoir de remplacement de la clearInstance()méthode. En fait, cette méthode n'est déclarée qu'une seule fois, dansapp/code/core/Mage/Core/Model/Abstract.php

final public function clearInstance()

J'ai vu des erreurs de cette nature se produire lorsque des personnes ont utilisé includepar erreur une classe surchargée (ce qui a entraîné son chargement deux fois).


Vos meilleures options sont de suivre la procédure de débogage standard

  1. Restaurer un noyau propre
  2. Restaurer un répertoire adminhtml propre
  3. Renommer le ./app/code/localrépertoire
  4. Renommer le ./app/code/communityrépertoire

Et voyez si le problème persiste.

Ben Lessani - Sonassi
la source
3

le problème ici est avec APC, désactivez APC et le problème disparaîtra.

Calvin Muller
la source
la désactivation d'APC n'est pas une option. Mais bonne idée! Je n'y penserais jamais! @sunlight avez-vous plus d'un magento installé? et défini le même préfixe? Cela pourrait être un problème avec un autre magasin dans le même cache.
Fabian Blechschmidt
3

selon les normes php pour cette erreur spécifique:

Erreur fatale: impossible de remplacer la méthode finale Mage_Core_Model_Abstract :: clearInstance () dans /var/www/html/app/code/core/Mage/Catalog/Model/Category.php sur la ligne 36

cela signifie clairement que vous avez étendu la classe en Mage_Core_Model_Abstractutilisant

class Mage_Catalog_Model_Category extends Mage_Catalog_Model_Abstract

et au sein de cette classe, vous avez clearInstance()défini comme une fonction.

Comme la clearInstance()fonction est une fonction finale, vous n'êtes pas autorisé à modifier cette fonction dans aucune des classes étendues.

quelle est exactement votre ligne 36 en ajoutant du code factice au-dessus et au-dessous de la ligne que vous supposez être la ligne 36.

J'avais vu des développeurs modifier ou rechercher des fichiers dans un dossier spécifique où, comme avec le compilateur défini sur les vrais fichiers de classe php, se trouve dans un autre dossier.

Oscprofessionnels
la source
J'ai vérifié, je n'ai aucune méthode nommée clearInstancedans localet communitypool. Cependant, j'ai supprimé le mot-clé final de la déclaration de fonction pour résoudre temporairement le problème, mais cela m'ennuie que lorsque j'ai rajouté le finalmot-clé à l'avant de la fonction, les choses fonctionnent toujours correctement.
lumière du soleil
Votre classe est probablement incluse deux fois comme indiqué par sonassi: j'ai vu des erreurs de cette nature se produire lorsque des gens ont utilisé par erreur include pour une classe surchargée (ce qui entraîne son chargement deux fois).
Oscprofessionals
2

J'ai eu le même problème avec la dernière version de PHP 5.4 sur une autre version de Magento (dans la zone frontend) et je n'ai pas pu résoudre cela par du code ou des caches. Avez-vous vérifié la version?

Si tel est le cas, un retour à la version antérieure vaut la peine d'être essayé.

Nico Siebler
la source
2

Je viens de vivre cela et j'ai trouvé une publication de bogue non confirmée indiquant une configuration très similaire.

Cela semble être un bug avec la combinaison de

  • PHP 5.4.12+
  • Magento 1.7.x (1.13.x EE)
  • APC (3.1.x)

Apache error_log affiche AH00052: erreur de segmentation du signal de sortie du pid XX enfant (11)

Actuellement, les deux meilleures solutions au problème semblent être les suivantes:

UNE) Rétrogradez PHP vers une version de travail inférieure, peut-être 5.4.11 ou inférieure.

B) Désactivez APC, si ce n'est pas possible, voir A. :)

B00MER
la source
Je rencontre le même problème avec PHP 5.3.27 avec MariaDB, Magento 1.7.0.2, sans APC. Im utilisant également Varnish + nginx. C'est un problème intermitent qui oblige à redémarrer php-fpm, vernis, nginx, etc. parfois. Au fait, je n'ai trouvé aucune méthode clearInstance non-core déclarée nulle part. Peut-être qu'il y a quelque chose, y compris les cours deux fois. Mais c'est étrange, car s'il s'agissait d'une erreur d'analyse, cela se produirait à chaque fois.
Ricardo Martins
1

J'ai résolu ces problèmes pour Magento 1.9 en changeant la façon dont PHP s'exécute (dans le panneau de contrôle d'hébergement, j'ai choisi Exécuter PHP en tant que ... pour Fast CGI Application). Je n'ai absolument aucune idée des autres conséquences de ce changement. Essayer de comprendre cela pour le moment.

matthijshofstede
la source
0

Je m'attendais au même problème. Il n'y avait aucune déclaration de méthode clearInstance en dehors du pool principal.

J'ai analysé mes nginx access.log et error.log et j'ai remarqué que ces erreurs apparaissent lorsque Google et Bing bots visitent mon site mille fois en quelques minutes dans différentes URL, faisant de nombreuses demandes et requêtes depuis magento. Ces choses détruisent mon site.

Je suppose que j'ai corrigé cela en diminuant la puissance du robot de Google et de Bing sur les panneaux de leur webmaster.

Vous pouvez utiliser GoAccess ou Request Log Analyzer pour analyser votre fichier journal et voir l'agent utilisateur le plus visité .

Ricardo Martins
la source