Mage :: log（）无法在新的Magento更新（1.9.4.1）上运行

在此新更新（1.9.4.1）之后，Mage :: log（）无法正常工作。显然，它与Zend_Validate_File_ExtensionMage.php的第819行有关，在此行中检查文件is_readable()是否存在。我将整个log()方法恢复为以前的版本，并且可以再次使用。

我可以联系Magento团队报告此问题的主要渠道是什么？

官方补丁来了:)还在等待官方补丁... :(

piotrekkaminski于13小时前评论

这是当前的官方补丁，将移植到早期版本（应该在最新版本上运行）https://gist.github.com/piotrekkaminski/0596cae2d25bf467edbd3d3f03ab9f8f

^{来源：https : //github.com/OpenMage/magento-lts/pull/648#issuecomment-480941871}

我将总结到目前为止所发现的一切内容，这些内容是基于研究和与Magento的支持以及Slack与SUPEE-11086修补之间的互动而得出的。可以做什么：

更新2：在下一个PATCH SUPEE-11155- https: //magento.com/security/patches/supee-11155中解决了该问题。一如往常，在应用补丁程序之前检查可能的问题线程- 安全补丁SUPEE-11155-可能的问题？感谢Aad Mathijssen的精彩评论。

更新：可以根据需要提供EE版本的官方补丁。基本上，这是Piotr Kaminski的要旨，被打包为Magento补丁文件。

1. 删除app/Mage.php补丁文件中的更改。到目前为止，这是我所做的。
   优点-记录与以前一样。
   缺点-编辑补丁文件，无法保护日志免受可能的利用（但这应该是非常低的风险）。当Magento发布官方修补程序时，您将必须还原它并应用原始的未编辑补丁。
2. 添加基于彼得·卡明斯基的要点上顶部的另一个补丁- https://gist.github.com/piotrekkaminski/0596cae2d25bf467edbd3d3f03ab9f8f。皮特·卡明斯基（Piotr Kaminski）是Magento负责安全的一部分，因此这直接来自马的嘴。Gist在Magento松弛中共享，可能会以SUPEE-11086 v1.1结尾。
   优点-这是Magento方式
   缺点-您将必须等待它正式发布，或者自己承担责任并将其打包为补丁程序，这将使您回到必须在正式补丁程序启动后恢复的状态。
   略有变化就是代替添加两个补丁以使用这些更改来编辑原始补丁。
3. 编辑Zend_Validate_File_Extension::isValid并删除文件存在验证。在Magento LTS github中有很长的讨论-https: //github.com/OpenMage/magento-lts/pull/648。该isValid方法可以完成预期的操作，因此一些成员建议对其进行修复。我的观点是，这不是一个好的解决方案，是的，代码很糟糕，但是它永远存在，并且可以在自定义模块/代码中使用。相反，最糟糕的情况是不会检查文件是否存在。
   优点-一个相当简单的解决方法
   -更改库文件并修改其功能。
   您可以将此应用为自定义补丁，也可以通过在local代码池中重写整个类来应用它。

我选择编辑补丁，当v1.1出现时，我将还原已编辑的补丁，并应用原始版本和该修复程序。这非常适合我们的构建过程和内部策略，可能与您有所不同。不管您选择什么，最好尽快应用此补丁。

来自社区的投入。Zend_Validate_File_Extension有一个新的验证器，如下所示：

https://github.com/brentwpeterson/magento-patches/blob/master/CE1.9/PATCH_SUPEE-11086_CE_1.9.4.0_v1-2019-03-26-03-05-04.sh#L183

“解决方案是编辑补丁，只是从app / Mage.php中删除更改，我强烈不鼓励这种做法，但是情况很危急”。

我临时的解决办法是复制lib/Zend/Validate/File/Extension.php到app/code/local/Zend/Validate/File/Extension.php并删除从代码的这部分isValid()方法：

    // Is file readable ?
    #require_once 'Zend/Loader.php';
    if (!Zend_Loader::isReadable($value)) {
        return $this->_throw($file, self::NOT_FOUND);
    }

它会变成...

public function isValid($value, $file = null)
{
    if ($file !== null) {
        $info['extension'] = substr($file['name'], strrpos($file['name'], '.') + 1);
    } else {
        $info = pathinfo($value);
...

当Magento 1.9.4.2发布时，我再次进行检查。

实际上，文件不可读或不存在，并不意味着文件名无效，对吗？

我建议不要更改核心代码，并使用像这样的更新（https://gist.github.com/mehdichaouch/99c67298b5a65f81219c9b69942b6fe7）

$installer->run("
    INSERT INTO `{$installer->getTable('core_config_data')}` (scope, scope_id, path, value)
    VALUES ('default', 0, 'dev/log/allowedFileExtensions', 'log,txt,html,csv')
    ON DUPLICATE KEY UPDATE value = 'log,txt,html,csv';
");

还有另一个问题（可能是Magento团队有意为之），该问题阻止了在子文件夹中写入日志文件的功能。例如：

Mage::log('Some log information', Zend_Log::DEBUG, 'somefolder/anotherfolder/somelogfile.log', true);

在早期版本中，该调用将在以下位置创建文件：

/your-magento-app-root-folder/var/log/somefolder/anotherfolder/somelogfile.log

但是既然有一个 basename()函数调用Mage::log()，因此文件写在：

/your-magento-app-root-folder/var/log/somelogfile.log。

这是中的代码app/Mage.php：

$file = empty($file) ?
    (string) self::getConfig()->getNode('dev/log/file', Mage_Core_Model_Store::DEFAULT_CODE) : basename($file);

即使它与1.9.4.1并没有特别关系，该问题还是最近才开始发生（大约是最新的1.9.3.x版本），当您不得不处理许多日志文件（有时名称相同（但最初在不同的子文件夹中）。

由于该代码段可能是Magento团队故意设计的，因此我认为没有计划在进一步的版本中对其进行修复，这意味着对其进行破解以恢复其初始行为...