如何覆盖app/code/core/Mage/core/functions.php中的Magento函数

如何覆盖app/code/core/Mage/core/functions.php中的Magento函数,function,magento,module,Function,Magento,Module,我需要重写此文件中的函数: app/code/core/Mage/core/functions.php 问题是,这是如此核心,以至于没有与之关联的类,可能是因为核心甚至不是一个模块。有人知道如何在没有类的情况下重写文件中的函数吗 任何帮助都将不胜感激 也许我没有正确理解你的问题,但为什么不把这个文件复制到 app/code/**local**/Mage/Core/functions.php 并在那里以任何方式修改它?由于以下原因,不应使用将文件复制到app/code/local/Mage/Co

我需要重写此文件中的函数:

app/code/core/Mage/core/functions.php

问题是,这是如此核心,以至于没有与之关联的类,可能是因为核心甚至不是一个模块。有人知道如何在没有类的情况下重写文件中的函数吗


任何帮助都将不胜感激

也许我没有正确理解你的问题,但为什么不把这个文件复制到

app/code/**local**/Mage/Core/functions.php

并在那里以任何方式修改它?

由于以下原因,不应使用将文件复制到app/code/local/Mage/Core/functions.php:

  • 必须复制整个文件,使我们更难确定所做的更改

  • 未来的升级可能会引入一些新功能,这些功能将不可用,除非记住在该文件的新版本中进行复制并再次实施更改

  • 未来的升级可能会解决核心的bug,我们将错过这些bug,除非记住在新版本的文件中进行复制并再次实现更改

  • 关于第2点和第3点,每次升级都可能改变工作方式,这意味着重新审视我们需要进行的更改。在某些情况下,重写方法也是如此,但至少我们可以很容易地确定这些更改对我们的影响

  • 如果另一个人想使用相同的技术,你会怎么做?能够识别什么是核心代码,什么是我们的代码变得越来越复杂

  • 将代码作为“模块”保存在一起变得更加困难,因为在核心文件中复制意味着我们已经有效地将其锁定为“保证”在复制原始代码的软件版本上运行。这也意味着重用这项工作要困难得多

  • 识别代码更改的原因要困难得多,因为它超出了我们的名称空间,即与“Example_Module”相关的所有开发都在名称空间中:

  • /应用程序/代码/核心/本地/示例/模块

    而复制到app/code/core/local/Mage的代码仅表示我们已进行了更改以支持未知功能等

    此外,Magento偶尔会发布修补程序来修复bug–这些修补程序只会修补core中的文件,而您复制的文件没有修补程序

    我建议您编写自己的函数来执行所需操作,并重写该函数来调用新函数。

    1。UOPZ 有一种方法不必从core复制和维护functions.php文件,但它涉及扩展名uopz(
    pecl install uopz
    ),然后您可以重命名magento的函数(例如从
    foo
    foo\u uopzOLD
    ),并定义您自己的()

    它的工作,是非常有用的magento-通常你会碰到一些你不能改变。在这种情况下,Uopz非常有用

    优点:有效;),您不必每次更新Magento时都重做它(如果操作正确,因为在内部您仍然可以调用
    foo\u uopzOLD
    ,因此在某些情况下,您可以确保某些向后兼容性)

    缺点:有点含蓄

    2.Composer安装后命令 如果您不喜欢上述内容,但使用composer,您可以修补任何需要的文件:

    "scripts": {
        "post-install-cmd": "patch -p0 < change-core-functions.patch"
     }
    
    • 抓住你的椅子
    • eval
      此账套;)
    正如@tweakmag所提到的,创建文件夹结构并复制整个模型或控制器以实现单个功能覆盖的缺点,最重要的是

    “未来的升级可能会引入一些新的功能,而这些功能是不可能实现的 除非记住要跨新版本的复制,否则可用 并再次实施更改。”

    因此,解决方案可以是,扩展核心类(模型或控制器),只编写要重写的方法,而不是复制所有方法

    例如,如果您想说,覆盖Mage\u Catalog\u Model\u Category中的方法getProductCollection,以下是步骤:

  • 创建一个自定义名称空间/模块文件夹,其中包含etc文件夹
  • 通过创建Namespace\u module.xml在app/etc文件夹中注册模块
  • 名称空间/Module/etc/中设置config.xml

    <?xml version="1.0"?>
      <config>
         <modules>
           <Namespace_Module>
             <version>1.0</version>
           </Namespace_Module>
          </modules>
          <global>
           <models>
            <catalog>
             <rewrite>
               <category>Namespace_Module_Model_Category</category>
             </rewrite>
            </catalog>
          </models>
         </global>
      </config>
    
    
    1
    名称空间\模块\模型\类别
    
  • Namespace_模块中创建Model文件夹和一个Php文件Category.Php

  • 现在这里的主要区别是我们扩展了Magento的核心类,而不是编写所有的方法

  • 我就是这样做的,记住本地代码池中的代码总是优先于核心代码池中的代码。magento autoloader的工作方式是,您可以简单地将树结构复制到本地,然后根据需要进行修改。嗨,戈登,是的,这是我到目前为止所做的-但我想将其制作成一个模块,以便人们更容易打开和关闭。工作正常,但相当脏。如果您不知道如何制作自定义模块(这是覆盖核心功能的首选方式),这更像是一种变通方法@Jhourlad,这只是一种临时解决方案!暂时的,直到有人在堆栈上有更好的答案,或者直到他升级到Magento2?你建议他写自己的函数,但你不告诉他如何写,我想这是他的问题的开始。我知道这是一篇老帖子,但如果“tweakmag”或任何其他人愿意继续回答,我相信它会帮助人们(包括我自己)。Tweakmag给出了很多不将核心代码复制到本地然后修改的好理由,但是
    
    <?xml version="1.0"?>
      <config>
         <modules>
           <Namespace_Module>
             <version>1.0</version>
           </Namespace_Module>
          </modules>
          <global>
           <models>
            <catalog>
             <rewrite>
               <category>Namespace_Module_Model_Category</category>
             </rewrite>
            </catalog>
          </models>
         </global>
      </config>
    
        <?php
         /**
          * Catalog category model
         */
          class Namespace_Module_Model_Category extends Mage_Catalog_Model_Category
           {
           public function getProductCollection()
            {
             // Include your custom code here!
             $collection = Mage::getResourceModel('catalog/product_collection')
             ->setStoreId($this->getStoreId())
             ->addCategoryFilter($this);
             return $collection;
           }
         }