补丁或核心破解

当我在系统升级项目中时，我要做的一件事情就是将客户端系统与全新的Magento安装进行比较。我正在寻找不属于标准Magento的核心hack或其他文件，以确保我能捕捉到以前的自由职业者，承包商，顾问或代理商所做的任何杂物，但对业务至关重要的工作。

补丁总是让我感到困扰的一件事。多年来，Magento发行了“版本间”补丁，通常是为了解决安全问题或更改运输/付款供应商的API。

问题是，从差异的角度来看，补丁与核心黑客是无法区分的，尤其是当您不知道已将哪些补丁（如果有）应用于系统时。

这导致了我的问题。

您如何区分核心hack和补丁？

支持人员提供的Magento补丁将在后面附加各种日志app/etc/applied.patches.list。我不知道补丁“脚本”执行该操作的时间或时间。CE补丁似乎也可以做到这一点。

这是我经常处理的事情（现在我正在研究），但是很遗憾，到目前为止，这是一个完全手动的过程-我们有一个自动化过程，标记每个文件，这些文件可能会在我们最初的自动审核中进行修改，一个新的支持客户。然后，我们让某人比较这些文件，并排除任何明显的误报（例如，空格更改）。

然后，有趣的部分-我们团队的资深成员与Magento一起工作了一段时间，必须查看结果以确定是否有任何修改后的文件可能是补丁的结果。我们已经考虑过更新系统以检查我们知道/可以使用的所有补丁，这可能对CE有用，但是在EE上则更具挑战性，因为EE支持有时会直接发布补丁永远不会发布任何其他方式或以一致方式进行分类的客户端。

因此，当我们进行此级别的审核时，我们将依赖于过去使用这些补丁程序的经验+常识（即，是否只是对API端点的更改？如果是这样，那么更改后的端点是否存在于更新版本中？如果是，这是一个补丁，可以忽略）。

从理论上讲，将CE下载页面等上的所有修补程序应用于所有适用的CE版本并进行检查比较简单（FYI，我们不使用diff作为第一遍-我们使用散列，部分是因为我们将这项技术内置到了可以远程检查站点而无需先下载该工具的工具中。这将排除大多数补丁，但是对于未发布到CE的公共下载区域或EE的客户端/受保护下载区域的任何CE或EE补丁仍然没有帮助。这将要求Magento制定一致的政策，即向所有客户提供所有补丁，并将这些补丁发布到我们可以得到的地方。

因此，不幸的是，在事物的Magento方面发生变化之前，我不认为有100％的自动化方法。

当我进行大量升级并尝试使过程系统化时，我采用的一种方法是将补丁直接直接提交到您用来比较的核心代码存储库中。

这实际上有两个好处：

1. 您的差异中不会再出现误报。

2. 假设您的网站没有特定的补丁程序。您可能会说这是一个问题，因为与技术上未打补丁的下载相比，即使从技术上讲它们没有丢失任何内容，它也会在差异中显示为缺少代码。但是实际上，他们缺少补丁实际上是一个应该解决的问题-因此，完美地将其显示在您的差异中供您修复升级。

我不认为最初在项目回购中包含Magento并不是一个好主意，以防您管理的客户超过2-3个。由于将应用系统补丁与核心黑客混在一起总是很容易的。

在我看来，最好的选择是拥有一个带有版本标签的作曲家Magento存储库镜像，该镜像指向特定的Magento版本，并应用可能的官方补丁。

同样，通过Composer通过与版本匹配您的Magento安装的版本号介绍它们的安装，也将使维护自己的文件补丁（例如用于高负载网站的Mage_Core_Model_Config和其他一些文件）更加容易。

因此，在这种情况下，将所有客户项目升级到修补的Magento代码，只会导致作曲者文件的版本增加。此外，将项目代码与核心区分开来，将迫使您的开发人员不要破解核心。

至于补丁和黑客的定义，我宁愿这样称呼它：

1. 官方补丁文件对原始核心文件的更改-这是一个补丁
2. 您的团队对原始核心文件进行了更改-这是骇客。
3. 为修复错误而对本地复制的核心文件进行的更改-这是一个补丁
4. 更改本地复制的核心文件以提供新功能-这是黑客

因此，通过将核心移至单独的存储库，您将确保您仅具有根据项目1的补丁版本。并且可以轻松地通过composer将自己的补丁安装到本地代码池中，因此您拥有根据点3的所有内容。和4您可以在项目存储库中创建一个git commit钩子，以禁止任何代码提交到该目录中。

我查看该文件/app/etc/夹中的已应用补丁文件，然后向后工作。但是，从升级中学到的知识，我只能删除其中包含已修补文件的版本上的文件，下次对其进行修补后，它是干净的。

Magento的任何功能都可以打一个补丁。其他一切都是骇客。