Magento 完全崩溃了：调用布尔值成员函数 getCode() & 未配置或找到 404 CMS 页面

https://magento.stackexchange.com//questions/87164

13-12-2019
|

题

突然（没有任何更改或更新）我们的 magento 安装似乎完全损坏了。

现在我们每天都会遇到一些这样的错误：

访问 /index 时未配置或发现 404 CMS 页面。
访问 /index 时突然出现 magento 安装程序
没有显示模板（如图所示）

奇怪的重定向。当一切似乎都正常时（没有 404 cms 错误，没有模板问题）并且我尝试访问产品，有时会被重定向到主页。

嗯，到目前为止我所做的是：

刷新缓存文件夹、刷新会话文件夹
截断表 core_url_rewrite

这似乎有效。重新索引（core_url_rewrite）后，一切似乎又被破坏了，所以我再次截断了。使用空 core_url_rewrite 看起来一切都很好。但第二天又坏了。

好吧，今天又是同样的情况，但这也是第一次刷新缓存、会话和 core_url_rewrite 不再起作用。

哦，这显示在我们的 nginx 错误日志中：

[错误]11773#11773：*242799 FastCGI 在 stderr 中发送：“PHP 消息：PHP 致命错误：在第 71 行上调用 /htdocs/seg_posorder/stage/app/code/core/Mage/Customer/Model/Session.php 中布尔值的成员函数 getCode()，同时从上游客户端读取响应头：217.24.X.X，服务器：www.example.com，请求：“GET /index.php/customer/account/login/ HTTP/1.1”，上游：“fastcgi://unix:/var/run/php5-fpm.sock:”，主机：“www.example.com”，引荐来源：“example.com”

但我们的商店似乎也还不错：

解决方案

后与聊天 @moose我决定自己将其作为答案发布。谢谢剩余感谢 @moose 指出我的文章，从而满足了我对 github 存储库上星星的无尽渴望。

有一个核心的 magento 配置缓存错误，会导致“未配置 404 CMS 页面”错误，或者在其他情况下导致“100 路由器匹配迭代”错误。当您刷新缓存时，该错误就会消失，但通常会在一段时间后重新出现。

https://github.com/convenient/magento-ce-ee-config-corruption-bug

（编辑：可以添加进一步的更改以防止配置损坏： https://github.com/convenient/magento-ce-ee-config-corruption-bug#update-2-further-improvements)

复制

查看我上面的存储库。

它有一个文件 100-路由器脚本.php 通过在网站的根目录中运行它应该可以帮助您复制错误。

补丁

Magento 已经根据我的文章发布了一个补丁（SUPEE-4755）。

PATCH_SUPEE-4755_EE_1.13.1.0_v1.sh

这个补丁与我的修复完全相同，这使其具有一定的有效性。

此补丁在任何地方都没有公开列出，因为Magento出于某种原因除了安全补丁以外，其他任何事情都不会这样做。我知道补丁文件说EE_1.13.1.0，但我在社区版1.9上对其进行了测试，并且应用了。

您可以在此处获取补丁的副本：https://github.com/convenient/magento-ce-ee-config-corruption-bug/blob/master/PATCH_SUPEE-4755_EE_1.13.1.0_v1.sh

由于历史原因或万一我的 github 帐户被删除

/**
* Initialization of core configuration
*
* @return Mage_Core_Model_Config
*/
public function init($options=array())
{
    $this->setCacheChecksum(null);
    $this->_cacheLoadedSections = array();
    $this->setOptions($options);
    $this->loadBase();

    $cacheLoad = $this->loadModulesCache();
    if ($cacheLoad) {
        return $this;
    }
    //100 Router Fix Start
    $this->_useCache = false;
    //100 Router Fix End
    $this->loadModules();
    $this->loadDb();
    $this->saveCache();
    return $this;
}

如果这不能修复您的 Magento 实例

这个补丁文件将解决所有合理的普通magento实例（任何使用定义的重新初始化配置缓存的东西） init 或者 reinit 方法）。

如果您有任何调用的代码 loadDb 类函数 n98-magerun - 那么你可能会度过一段糟糕的时光，并且可能应该考虑重构你的代码来调用 reinit 或者 init 在 Mage_Core_Model_Config.

如果您仍然遇到问题，我建议您阅读我的文章并

实现中提到的逻辑调试问题部分。
等待一些日志数据出现。
联络我！

关于为什么 supere 6788 使错误变得更糟的理论

我刚刚将其发布在聊天室中，并想将其发布到此处以供后代使用。

要记住的是，Magento在其背景下始终有此错误。那个Supee 6788刚刚使它更有可能发生

我刚刚看了 EE1.14 的 supere 6788 补丁这是我的工作理论。

Mage_Core_Controller_Varien_Router_Admin 已修补以覆盖 addModule 功能

现在，我不太记得法师请求初始化期间发生的事情的顺序，但此修改现在在每个请求上添加了对 Mage::getConfig()->getNode() 的两次调用，这在流程的早期阶段。如果在这两个调用期间 useCache 出现对象缓存参数失败，则可能会触发将不完整的配置写入缓存（getNode 可以触发重新初始化，因为它尝试从缓存加载值，并且在加载失败，它将重新初始化整个配置缓存并通过 reinit() 函数重新保存）

因此，也许只需在请求的很早的部分中添加这两个额外的nodes，当可能无法加载完整的配置时，可能会导致此错误发生，无论哪种方式，我都不会全面了解该问题。这不是很多收益将是很多工作，并研究mage_core_model_config :: loaddb（重点关注usecache标志可能对它的影响）可能会使男人疯狂。

其他提示

您描述的问题，只有2点特别熟悉，但对于它的价值而言，我们如何在我们的案例中解决它：

php的libxml库中有一个错误 - 我认为它是这个 - 这意味着有时Magento无法加载其一些自己的配置文件。您可能会发现它是一些低级更新（PHP或其依赖的库中的一个，它在开放中带出问题。

尝试将此行添加到index.php，靠近开始（我将它放在PHP版本检查后）：

libxml_disable_entity_loader(false);

nexcess （magento platinum hosting partner）将我指向github上的解决方案（大熊到 luke rodgers ，修补程序的作者）

magento错误 - 损坏配置缓存

patch_supee-4755_ee_1.13.1.0_v1.sh

此修补程序与我的修复完全相同，这会给它提供一些有效性。

这个补丁在任何地方都没有公开列出，因为magento不做出于某种原因的安全补丁，任何事情都是如此。我知道这一点补丁文件说EE_1.13.1.0，但我在Community Edition 1.9上测试了它它申请精细。

此页面给您一个完整的解释通过运行 100-router-script.php 来自您的根目录（这为我复制了问题，先尝试）。

修复：

/**
* Initialization of core configuration
*
* @return Mage_Core_Model_Config
*/
public function init($options=array())
{
    $this->setCacheChecksum(null);
    $this->_cacheLoadedSections = array();
    $this->setOptions($options);
    $this->loadBase();

    $cacheLoad = $this->loadModulesCache();
    if ($cacheLoad) {
        return $this;
    }
    //100 Router Fix Start
    $this->_useCache = false;
    //100 Router Fix End
    $this->loadModules();
    $this->loadDb();
    $this->saveCache();
    return $this;
}

它继续说：

我认为这将是彻底解决的对于每个人magento设置的问题。如果它对你不起作用推荐你

在调试问题部分中实现逻辑。

等待出现一些日志数据。

联系我！

因为我很长一段时间没有任何答案（我们的商店正在制作客户，我需要提出自己的解决方案。我会分享它，也许它可以帮助找到问题：

在我的index.php中我改变了：

/* Store or website code */
$mageRunCode = isset($_SERVER['MAGE_RUN_CODE']) ? $_SERVER['MAGE_RUN_CODE'] : '';

/* Run store or run website */
$mageRunType = isset($_SERVER['MAGE_RUN_TYPE']) ? $_SERVER['MAGE_RUN_TYPE'] : 'store';

Mage::run($mageRunCode, $mageRunType);

至：

$mageRunCode = 'default';
$mageRunType = 'store';

Mage::app()->setCurrentStore(1);
Mage::run($mageRunCode, $mageRunType, array('is_installed' => true));

这是硬编码的，只有工作，因为我们只有一家商店。但仍然，它似乎现在工作。

许可以下： CC-BY-SA 和归因

不隶属于 magento.stackexchange