进行 Magento 更新的最佳实践? [英] Best practice for conducting a Magento update?

问题描述

进行 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 代码相对应的文件.

move in all files to your empty dir (note that you have removed the .git dir from your existing site after making it comparable) from your fcked up magento installation (they are comparable now) and run a git status > changes.txt . This file now lists every difference you have , any new file you have, any deleted, renamed, etc file you have on your "fcked up installation" against the clean Magento code that you are currently on.

基于评论的解释:我通常做git status --porcelain

Explaining based on comments: I usually do git status --porcelain

有一个 .gitignore 文件可以帮助您丢弃 local.xml var/* 或不需要版本控制的每个文件/目录，以及 .DS_Store、.Thumbs.db 和您创建的 ide来自 git 的项目文件.您不需要版本控制上的所有媒体和缓存文件以及每个服务器中不同的文件.

have a .gitignore file in place to help you discard local.xml var/* or every file/dir that you don't need to version control and also .DS_Store, .Thumbs.db and your ide created project files from git. YOu don't need all Media and cached files and files that are different in each server on your version control.

从那里您应该仔细浏览该列表，并根据该列表:

From there you should overview that list carefully and based on that list you should:

• 将每个核心更改移动到 app/code/local/并将更改的文件检出到其原始状态(保留复制的文件并使用 git checkout filename 丢弃核心中的更改)
• 将每个更改的核心模板和布局文件移动到您自己的主题文件夹并将更改的文件签出到其原始状态
• 恢复或迁移 .htaccess 更改或决定是否需要保留或丢弃

现在你的状态仍然很差，但你现在:

Now you still are in bad shape but you are now:

• 基于干净的核心
• 基于单独分支中的版本化主树

现在您可以受益于版本控制、可比较和基于主分支的单独分支，其中包含可合并的 Magento 版本.因此，让我们尝试升级，这是 100% 成功的关键点.

Now you can benefit on being version controlled, comparable and in separate branch based on your master branch that has mergable versions of Magento in it. So lets try to upgrade, here's the key points of 100% success on doing this.

1. 第一步是禁用您现在已分离到 app/code/local/Mage/和分离主题的所有废话".如果您的核心是明确的并且可以禁用主题，那么您就没有干扰升级过程的自定义代码.所以继续禁用:

1. first step would be disable all the "crap" that you have now separated to app/code/local/Mage/ and to separate theme. If your core is clear and themes can be disabled you have no custom code interfering with upgrade process. So go ahead disable:

• 通过将所有本地扩展和自定义社区扩展移出 app/etc/modules/到临时文件夹，让它成为 app/etc/inactive/
• 禁用自定义主题并打开基本/默认/
• 这是您处于可比状态的好处.你知道有什么不同，你可以禁用它并根据它进行诊断

现在，如果您的 repo 中的主树中的所有主要版本都单独标记或分支，那么提高版本只是一个命令:git merge "magento-vhateverthenextversionis"

now if you have all major versions in the master tree in your repo tagged or branched separately then getting the version higher is just a command away: git merge "magento-vhateverthenextversionis"

• 再次执行此操作后，git status > changes.txt"将为您提供版本之间所有更改文件的列表
• 在浏览器上执行站点将执行升级，并且由于您使用的是默认主题且未激活任何自定义，因此它会像魅力一样执行
• 按版本重复升级版本并通过在测试分支中添加标签来保存代码状态，或者根据现有测试分支为每个版本创建一个新分支，这样您就为中间升级的每个 magento 版本保存了干净的状态
• 这里还有一个额外的好处是，如果您使用版本控制来执行此操作，您还将摆脱新版本丢弃的文件，您可以轻松删除它们

如果您已经将 2. 迭代到您想要的 magento 版本到最新，那么是时候吃掉您继承的s*it"并执行以下操作:

if you have iterated the 2. to your desired magento version to latest then it is time to eat the "s*it" that you have inherited and do following:

• 分析您拥有的所有扩展程序，看看它们是否可以升级，如果您可以升级并打开，看看它们是否适用于默认主题
• 将 app/code/local/Mage 中的每个内核重写与来自 app/code/core/Mage 的新形式的原始版本进行比较.您可以使用差异工具，例如 winmerge.org 或更改(无论您喜欢哪种操作系统和工具)或更改整个文件夹
• 同样适用于您的模板和覆盖的模板或布局.与原始模板进行比较并将您的更改合并到新的基本模板并摆脱旧的 DOM
• 一一开启主题更改和扩展并调试

如果你到了这一点，那么你已经完成了一大堆工作，这取决于安装有多混乱，它可能需要几天时间.但是，嘿现在你有一个干净的 magento 核心，它是版本控制的，单独的覆盖合并和概览，以及可以禁用的单独主题中的所有内容.

if you get to this point then you have done a shitload of work , dependant how messed up the installation is it can take days. But hey now you have a clean magento core that is version controlled, separated overwrites that are merged and overviewed , and all stuff in separate theme that can be disabled.

有趣的部分是，如果 magento 的下一次升级可用，您可以吹口哨并将其添加为与您的主树相当并合并更改，了解更改的内容并对要概述和测试的内容有明确的范围.

fun part is that if next upgrade of magento is available you can whistle and add it as comparable to your master tree and merge down the changes, know what is changed and have a clear scope on what to overview and test.

这篇关于进行 Magento 更新的最佳实践?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！