私がシステムアップグレードプロジェクトを行っているとき、私がしていることの1つは、Magentoの新規インストールに対してクライアントのシステムを比較することです。以前のフリーランサー、請負業者、コンサルタント、または代理店によって行われた手抜きだがビジネスに不可欠な作業を確実にキャッチするために、標準のMagentoの一部ではないコアハックまたは追加ファイルを探しています。
いつも私を困らせることの1つは、パッチです。長年にわたり、Magentoは「バージョン間」パッチを発行してきました。通常、セキュリティ修正、または出荷/支払いベンダーのAPIの変更に対処するためです。
問題は、diffの観点から、特にシステムに適用されているパッチ（ある場合）がわからない場合、パッチがコアハックと見分けがつかないことです。
それが私の質問につながります。
コアハックとパッチをどのように区別しますか？
回答:
サポートが提供するMagentoパッチは、種類のログをに追加しますapp/etc/applied.patches.list。パッチの「スクリプト」がいつ、どのくらいの期間これを行っているのかわかりません。CEパッチもこれを行うようです。
これは私が頻繁に対処するものであり（現在作業中です）、残念ながら、これまでは完全に手動のプロセスです。最初の自動監査の一部として変更される可能性のあるすべてのファイルにフラグを立てる自動化プロセスがあります新しいサポートクライアント。その後、誰かにそれらのファイルを差分させ、明らかな誤検知（つまり、空白の変更）を除外します。
それから、楽しい部分-かなり長い間Magentoで働いてきた私たちのチームのシニアメンバーは、修正されたファイルがパッチの結果である可能性があるかどうかを判断するために結果を調べなければなりません。私たちはシステムを更新して、認識している/手に入れることができるすべてのパッチをチェックすることを検討しましたが、CEではうまくいくかもしれませんが、EEサポートはパッチを直接発行することがあるため、さらに困難です他の方法でリリースされたり、一貫した方法でカタログ化されたりしないクライアントに。
したがって、このレベルのレビューを行う場合、これらのパッチと常識を適用した過去の経験に依存します（つまり、それはAPIのエンドポイントの単なる変更ですか？その場合、その変更されたエンドポイントは更新バージョンに存在しますか？その場合、これはパッチであり、無視できます）。
CEダウンロードページなどで利用可能なすべてのパッチをCEの該当するすべてのバージョンに適用し、それらをチェックすることは理論的には簡単です（FYI、最初のパスではdiffを使用しません-ハッシュを使用します。これは、最初にダウンロードする必要なくサイトをリモートでチェックできるツールにこのテクノロジーを組み込んだためです）。これはパッチの大部分を除外しますが、CEのパブリックダウンロードエリアまたはEEのクライアント/保護されたダウンロードエリアにポストされていないCEまたはEEパッチについては依然として役に立ちません。そのためには、Magentoがすべての顧客がすべてのパッチを利用できるようにする一貫したポリシーを作成し、それらを入手可能な場所に投稿する必要があります。
残念ながら、Magento側で変更が発生するまで、これを100％自動化する方法はないと思います。
git diff depot/master origin/masterです。課題は.gitignoreです。別のオプションは、バージョンを別のディレクトリに複製し、その上にサイトのapp/code/coreディレクトリをコピーすることです。git diff -wその後、教えてくれます。
多数のアップグレードを行ってプロセスを体系化しようとしたときに私がこれにアプローチした1つの方法は、実際にパッチを直接差分を使用するコアコードリポジトリにコミットすることでした。
これには、実際には2つの利点があります。
差分に誤検出が表示されなくなりました。
特定のパッチがないサイトがあるとしましょう。パッチが適用されていない新しいダウンロードと比較して、技術的には何も欠落していないにもかかわらず、差分に欠落コードとして表示されるため、これは問題だと言えるかもしれません。しかし、実際には、パッチが欠落しているということは実際には解決すべき問題です。したがって、アップグレードに合わせて修正するために差分に表示されるのは完璧です。
プロジェクトリポジトリにMagentoを置くことは、2〜3以上のクライアントを管理する場合に最初は良い考えだとは思いません。適用されたシステムパッチをコアハックで台無しにする方が常に簡単だからです。
私の意見では、最良の選択肢は、作曲家のMagentoリポジトリミラーにバージョンタグを付けて、公式パッチが適用された特定のMagentoバージョンを指すようにすることです。
また、Magentoのインストールに一致するバージョン番号をコンポーザー経由で導入することにより、高負荷のWebサイトや他のいくつかのWebサイトのMage_Core_Model_Configなどのファイルへの独自のパッチの維持が容易になります。
そのため、この場合、パッチを適用したMagentoコードへのすべての顧客プロジェクトのアップグレードは、コンポーザーファイルのバージョンバンプのみになります。また、プロジェクトコードをコアとは別にしておくと、開発者はコアをハッキングしないようになります。
パッチとハックの定義については、次のように呼び出したいと思います。
したがって、コアを別のリポジトリに移動することにより、項目1に従ってパッチを適用したバージョンのみを確認できます。また、独自のパッチをコンポーザー経由でローカルコードプールに簡単にインストールできるため、ポイント3に従ってすべてを取得できます。また、4プロジェクトリポジトリにgit commitフックを作成して、そのディレクトリへのコードコミットを禁止できます。
その/app/etc/フォルダ内の適用されたパッチファイルを確認し、逆方向に作業します。しかし、アップグレードから学んだように、パッチを適用したファイルが含まれているバージョンのファイルを削除するだけで、次回パッチを適用しても問題はありません。
Magentoからの何かは、パッチと呼びます。それ以外はすべてハックです。