进行 Magento 更新的最佳实践?

问题描述

进行 Magento 更新(维护不善的 Magento 安装)的最佳做法是什么.

What is the best practice for making a Magento update (of a badly maintained Magento installation).

我想到了以下几点:

• 查看 app/code/local 中的完整覆盖模块 - 将文件与旧版本进行比较，并将它们转发到新的 Magento 版本
• 比较模板
• 比较布局 XML 文件(如果它们被直接复制到自定义主题文件夹并且没有使用仅包含真实更新的单个 layout.xml)
• 比较重写类的方法与原始类的方法

主要问题是:在旧的、维护不善的 Magento 安装中比较文件时，您永远不知道复制的原始文件具有哪个版本.有时我试图通过查看文件注释中的 Magento 版权来识别旧版本.

The main problem is: When diffing files in old, badly maintained Magento installations, you never know, which version the original file that was copied had. Sometimes I tried to identify the old version by having a look on Magento's copyright in the file comment.

为了避免更新过程中的麻烦，我们通常会执行以下操作:

To avoid hassle during update we usually do the following:

• 避免重写，改用事件
• 如果需要重写，尽量不要复制代码，而是调用 parent::method() 以在被覆盖的类中只保留必要的功能
• 如果需要复制代码，请使用标记注释，例如 [Mycompany BEGIN] ... [Mycompany END]
• 不要复制整个布局文件，而是使用一个只进行更新的 layout.xml.

但是如果没有采取这些预防措施，如何进行更新?

But how to do an update if those precautions where not taken?

推荐答案

正如其他人所指出的，这里的关键是让它与干净安装相媲美，所以这里是我将在版本控制的帮助下做的事情.

As others have noted the key here is to make it comparable against clean installation so here's what I would do with the help of version control.

1. 让自己获得当前使用的 Magento 的干净版本，并且不要忘记使其具有可比性.或者使用现有的 magento git 镜像(参见更多 http://blog.speedupmate.com/post/4063307705/magento-git-mirror )

根据 1. 在这里设置一个主存储库并准备好

set up a master repo based on 1. here and have it at hand

在评论中提问:您的最终目标是拥有一个干净的核心，其中包含 magento 安装文件中存在的 git 中的所有文件.这是必需的，因此您可以将所有内容与全新安装进行比较.管理核心更改，核心文件树(现有、不存在、添加的文件).您可以使用 .gitignore 处理您的异常(不包括媒体、缓存、具有服务器特定范围 local.xml .htaccess 的所有字段).我发现将 Magento 核心文件移出到不同的(非公共)目录很容易(如此处所述 http://blog.speedupmate.com/post/9992573819/poor-mans-multisite-setup-for-magento )，这会给我一个代码状态，其中 .htaccess 从不升级冲突.我也从未在版本控制、缓存和 magento 生成的所有临时文件中包含媒体.这将保证您的升级路径清晰，因为您可以在升级时间内禁用所有功能.稍后比较代码将为您提供需要概览的范围，并且您可以估算比较更改的部分并进行升级所需的时间.

Asked in comments: Your ultimate goal is to have a clean core with all files in git that are present in magento installation files. That is needed so you can compare everything against the clean installation. Managing core changes, core filetree (existing, non-existing, added files). You can handle your exceptions with .gitignore (excluding media , cache, all fiels with server specific scope local.xml .htaccess). I find it easy to move out Magento core files to different (non public) directory (as explained here http://blog.speedupmate.com/post/9992573819/poor-mans-multisite-setup-for-magento ) and that will give me a code state where .htaccess never conflicts on upgrade. I also never include media in version control , cache and all temporary files that magento generates. This will guarantee you clear path on upgrades as you can disable all for the upgrade time. Comparing the code later will give you scope of things you need to overview and you can estimate how long it will take you to compare the changed parts and go live with upgrade.

现在使用您现有的站点和 git config(使其具有可比性)在您的代码库上执行 git init 并将所有内容添加到 git 那里，这将检查您的 git 配置并使每个文件具有可比性(相同的换行符、空格等)，然后将文件权限修复为相同.之后，您可以从您的站点中删除 .git 文件夹，因为您只使用 git 在那里制作可比较的文件.

now with your existing site and git config in place (to make it comparable) do a git init on your codebase and add everything to git there , this will go over your git config and make every file comparable (same newlines, whitespaces etc) then fix file permissions to be the same. After that you can remove the .git folder from your site as you only used git to make files comparable there.

在评论中提问:这里的重点是让 git 为您工作，例如将所有行结尾转换为 unix 样式并忽略空格，理论上您也可以忽略权限，但这没有用(这里的格式有点不对，所以 代表命令之间换行

Asked in comments: The point here is to have git do work for you like converting all line endings to unix style and ignore whitespaces, you can ignore permissions too in theory but that's not useful (formatting is bit off here so represents a line break between commands

git config core.autocrlf 输入 git 配置 core.eol lf git config apply.whitespace nowarn

现在如果你执行 git init并添加这些配置并将所有内容添加到 git 然后在提交阶段 git 将替换您所有的 Windows 行结尾和所有废话，以统一和可比较的样式.请注意，zend 编码标准建议使用 unix 样式的行结尾，但是您也会看到 Zend 库不遵循其自身标准的文件.这里的关键点是您需要您的文件具有可比性，以最大限度地减少您必须做的差异负载.在 git 为您格式化所有错误的安装文件后，您将删除 .git 文件夹.Git 仅用于自动化此步骤中的使事物具有可比性的过程"，没有其他作用

Now if you do git init and add those configs and add everything to git then during committing stage git will replace all your windows line endings and all that crap to unified and comparable style. Note that zend coding standard suggest unix style line endings however you will also see the files where Zend library does not follow it's own standards. Key point here is that you need your files to be comparable to minimize the diff load you have to do. You will remove the .git folder after git has formatted all your bad installation files for you. Git is only used to automate the "make things comparable process" in this step and nothing else

根据 1. 中的主存储库签出您的测试存储库，并使用您当前所在的版本签出一个分支并将其命名为testsomething"或您需要的任何名称

checkout your test repository based from your master repo in 1. and checkout a branch with the version you are currently on and name it "testsomething" or whatever you need

删除该结帐文件夹中的所有内容并仅保留 .git 以使其为空，但版本控制仍然存在.它将处于所有内容都已删除的状态，这在这里很重要，因为您将知道您可能在不良站点上删除了哪些文件.

delete everything from that checkout folder and leave only .git in place so it is empty but version control still exists there. It will be in state like everything is deleted and this is important here cause based on that you will know what files you might have deleted on your bad site.

在评论中提问:我通常在 git config 中添加忽略空格(本地或全局范围可用)并让 git 为我处理.在团队中工作时，我们总是同意基于 Zend 的标准:4 个空格用于制表符、unix 样式行结尾和 3 中提到的 git 配置变量.如果涉及构建脚本，我们会使用提交钩子进行代码格式化和验证.

Asked in comments: I usually add whitespace ignoring to git config (local or global scope is available) and let git handle that for me. When working in teams we always agree on based Zend standards: 4 spaces for tabs, unix style line endings and git config variables mentioned at 3. and if build scripts are involved we do code formatting and validation with commit hooks.

将所有文件移动到您的空目录中(请注意，您已将 .git 目录从现有站点中删除，使其具有可比性)从您的 fcked magento 安装(它们现在可以比较)和运行 git status >更改.txt .该文件现在列出了您拥有的所有差异、您拥有的任何新文件、任何已删除、重命名的文件，以及您在安装"中与当前使用的干净 Magento 代码相对应的文件.