进行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.

• Avoid rewrites, use events instead
• If rewrites are necessary, try to not copy code but call parent::method() to keep only the necessary functionality in the overwritten class
• If copying code is necessary, use a marker-comment such as [Mycompany BEGIN] ... [Mycompany END]
• Do not copy entire layout files but use a single layout.xml that does only updates.

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

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核心文件移至其他(非公共)目录很容易(如此处

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 config并使每个文件具有可比性(相同的换行符，空格等)，然后将文件权限固定为相同.之后，您可以从站点中删除.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 input \ git config core.eol lf \ git config apply.whitespace nowarn

git config core.autocrlf input \ git config 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的标准:在3中提到了制表符，unix样式行结尾和git config变量的4个空格，如果涉及构建脚本，我们将使用提交钩子进行代码格式化和验证.

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 dir).运行git status > changes.txt.现在，此文件列出了"f cked up安装"中与当前使用的干净的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更改或决定是否需要保留或丢弃

• move every core change to app/code/local/ and checkout the changed file to it's original state (keep the copied one and discard the changes in core with git checkout filename)
• move every changed core template and layout file to your own theme folder and checkout the changed file to it's original state
• revert or migrate .htaccess changes or decide if you need to preserve or discard

现在，您的状态仍然很糟，但是现在:

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

• 基于干净核心
• 基于版本控制的主树，位于单独的分支中

现在，您可以受益于版本控制，可比较并且在单独的分支中受益，该分支基于其中包含可合并的Magento版本的master分支.因此，让我们尝试升级，这是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. 第一步是禁用所有您现在已经分离到应用程序/代码/本地/法师/主题主题的废话".如果您的核心清晰并且可以禁用主题，则您没有自定义代码来干扰升级过程.因此，请继续禁用:

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/移到temp文件夹，使其成为app/etc/inactive/
• 禁用自定义主题并打开base/default/
• 这是处于可比较状态的好处.您知道有什么不同，可以禁用该功能并根据该功能进行诊断

现在，如果您的存储库中的主树中有所有主要版本标记或单独分支，那么将版本提高就可以了: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/core/Mage中的新形式，将每个核心重写为app/code/local/Mage中的原始版本.您可以使用诸如winmerge.org之类的差异工具，也可以一一更改或更改整个文件夹(无论您喜欢哪种操作系统和工具)
• 模板和覆盖的模板或布局相同. COmpare原始并将您的更改合并到新的基本模板中，并摆脱旧的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屋！