管理员页面中的致命错误

我已经安装了magento 1.7，并且到目前为止效果还不错。

我每天进口产品。如果有任何新的制造商，则将其添加到基于“制造商”属性的下拉列表中。

今天，我在属性后端添加了新的制造商选项，并成功导入了产品。

但是之后，我尝试在Magento管理站点中打开任何页面，最终显示以下错误消息

致命错误：在第36行的/var/www/html/app/code/core/Mage/Catalog/Model/Category.php中无法覆盖最终方法Mage_Core_Model_Abstract :: clearInstance（）

该课程的线36刚刚开始卷曲{

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

我已经检查过，Mage_Catalog_Model_Category但是没有用name定义的方法clearInstance。真烦人。

仅供参考：我没有碰到一个单一的代码字符，我只是使用ADMIN网站导入产品并添加了一些必需的属性

除非您以某种方式修改了Magento的代码-通常是通过第三方扩展，核心代码编辑或常规定制，否则这种行为通常不会发生。

它实际上是在管理员中发生的，实际上是在加载任何数据模型之前（产品网格等），这暗示它是由扩展而不是导入的数据引起的。

它发生在产品网格上-然后可能是由于导入失败导致产品模型出现故障。

但是经过快速搜索后，Magento商店中有很多索引过的Google搜索结果都带有相同的错误。因此它可能处于核心位置（尽管我们从未遇到过）-但我对此表示怀疑。

看1.7的核心

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

您不应对该clearInstance()方法进行任何覆盖。实际上，此方法仅声明一次，在app/code/core/Mage/Core/Model/Abstract.php

final public function clearInstance()

我已经看到这种错误是由于人们错误地使用include了一个被覆盖的类而导致的（导致该类被加载两次）。

最好的选择是遵循标准的调试过程

1. 恢复干净的核心
2. 恢复干净的adminhtml目录
3. 重命名./app/code/local目录
4. 重命名./app/code/community目录

并查看问题是否仍然存在。

这里的问题是APC，禁用APC，问题将消失。

按照php标准针对此特定错误进行操作：

致命错误：在第36行的/var/www/html/app/code/core/Mage/Catalog/Model/Category.php中无法覆盖最终方法Mage_Core_Model_Abstract :: clearInstance（）

它显然意味着您已经Mage_Core_Model_Abstract使用

class Mage_Catalog_Model_Category extends Mage_Catalog_Model_Abstract

在该类中，您已将clearInstance()其定义为函数。

由于clearInstance()函数是最终函数，因此不允许您在任何扩展类中修改此函数。

通过在您假设的第36行之上和之下添加一些伪代码，您的第36行到底是什么。

我见过开发人员修改或查看特定文件夹中的文件，其中将编译器设置为true php类文件时，该文件位于其他文件夹中。

我在不同的Magento版本（位于前端区域）中使用最新的PHP 5.4版本时遇到了相同的问题，无法通过代码或任何缓存解决。您检查版本了吗？

如果是这种情况，则可以尝试回滚到早期版本。

刚刚经历了这一点，发现了一个未经证实的错误发布，指出非常相似的设置。

这似乎是一个错误，结合了

• PHP 5.4.12+
• Magento 1.7.x（1.13.x EE）
• APC（3.1.x）

Apache error_log显示AH00052：子pid XX退出信号分段错误（11）

• https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=953883

目前看来，该问题的两个最佳解决方案是：

A）将 PHP降级到较低的工作版本，可能是5.4.11或更低。

B）禁用APC，如果不能的话，请参见A. :)

• http://blog.stillaslife.com/work/magento-fatal-error-with-php-5-4-12/

我通过切换PHP的运行方式解决了Magento 1.9的这个问题（在托管控制面板中，我将Run PHP as ...夹在了Fast CGI Application中）。我完全不知道这种变化还会带来什么其他后果。现在试图弄清楚。

我期待着同样的问题。核心池之外的任何地方都没有clearInstance方法声明。

我分析了我的nginx access.log和error.log，发现当Google和Bing僵尸程序在几分钟之内用不同的URL访问我的网站一千次时，就会出现这些错误，并从magento发出许多请求和查询。这件事使我的网站瘫痪了。

我猜我是通过降低Google的抓取工具功能并在其网站站长面板上获取动力来解决此问题的。

您可以使用GoAccess或“ 请求日志分析器”来分析您的日志文件，并查看访问量最高的用户代理。